U.S. patent application number 11/932498 was filed with the patent office on 2008-10-30 for method and apparatus for real time online credit approval.
Invention is credited to Yinzi Cai, Timothy J. Coltrell, David W. Dowhan, Jeremy R. Lent, Mary Lent, Eric R. Meeks.
Application Number | 20080270295 11/932498 |
Document ID | / |
Family ID | 22680019 |
Filed Date | 2008-10-30 |
United States Patent
Application |
20080270295 |
Kind Code |
A1 |
Lent; Jeremy R. ; et
al. |
October 30, 2008 |
Method and Apparatus for Real Time Online Credit Approval
Abstract
A system and method are described for providing real time
approval of credit over a network. The method includes obtaining
applicant data from an applicant. The applicant data is analyzed
into a form suitable for directly obtaining a credit report from a
credit bureau for the applicant. A credit report having credit
report data is obtained from a credit bureau for the applicant. It
is then determined whether to accept the applicant using the credit
report data and it is communicated to the applicant that the
applicant has been approved.
Inventors: |
Lent; Jeremy R.; (Corte
Madera, CA) ; Lent; Mary; (Corte Madera, CA) ;
Meeks; Eric R.; (San Francisco, CA) ; Cai; Yinzi;
(Fremont, CA) ; Coltrell; Timothy J.; (Danville,
CA) ; Dowhan; David W.; (Mountain View, CA) |
Correspondence
Address: |
GARDERE WYNNE SEWELL LLP;INTELLECTUAL PROPERTY SECTION
3000 THANKSGIVING TOWER, 1601 ELM ST
DALLAS
TX
75201-4761
US
|
Family ID: |
22680019 |
Appl. No.: |
11/932498 |
Filed: |
October 31, 2007 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10901715 |
Jul 28, 2004 |
|
|
|
11932498 |
|
|
|
|
09595601 |
Jun 15, 2000 |
6795812 |
|
|
10901715 |
|
|
|
|
09185201 |
Nov 3, 1998 |
6405181 |
|
|
09595601 |
|
|
|
|
Current U.S.
Class: |
705/38 |
Current CPC
Class: |
G06Q 30/06 20130101;
G06Q 40/02 20130101; G06Q 40/025 20130101; G06Q 40/08 20130101 |
Class at
Publication: |
705/38 |
International
Class: |
G06Q 40/00 20060101
G06Q040/00 |
Claims
1. A method implemented on one or more computers for providing
approval of credit over a network, comprising: receiving via a
computer network applicant data from an applicant for a credit
application; prior to obtaining credit report data from a credit
bureau for the applicant, determining compliance of the applicant
with one or more one or more requirements, the one or more
requirements comprising a duplicate check comprising comparing one
or more elements of the applicant data with data previously
submitted by previous applicants; transmitting electronically to
applicant a determination to decline approval for credit to the
applicant if the applicant data fails to meet one or more of the
one or more requirements; if the applicant is not declined:
processing one or more elements of the applicant data into a
predetermined electronic form; electronically transmitting the one
or more elements of applicant data in the predetermined electronic
form to a credit bureau for obtaining a credit report from a credit
bureau for the applicant; receiving electronically the credit
report data from a credit bureau for the applicant; and
determining, without intervention of a human, whether to approve or
reject the applicant based for credit based at least in part on the
credit report data; and if it is determined to approve the
applicant for credit, communicating electronically to the applicant
that the applicant has been approved for credit.
2. The method of claim 1, wherein the determination of whether to
approve the applicant for credit occurs in real time.
3. A system for providing approval of credit over a network
implemented on one or more computer processors, comprising: an
application engine configured to obtain applicant data from an
applicant; an address parser configured to format the applicant
data into a form suitable for directly obtaining a credit report
from a credit bureau for the applicant; and an underwriter module
configured to: determine whether to continue to process or to
reject the applicant based on the applicant data prior to obtaining
a credit report from a credit bureau for the applicant, said
determining whether to continue to process comprising: checking
based on the applicant data entered by the applicant and prior to
obtaining a credit report whether some or all of the applicant data
is a duplicate of applicant data previously entered by the
applicant; and declining the applicant, in the event it is
determined that the applicant data is a duplicate of applicant data
previously entered by the applicant after a predetermined
duplication cutoff date; and obtain, in the event it is determined
based on the applicant data to process the applicant, a credit
report having credit report data from a credit bureau for the
applicant; determine whether to accept the applicant using the
credit report data; and, communicate, if it is determined to accept
the applicant for credit, to the applicant that the applicant has
been approved for credit.
4. The system of claim 3, wherein the determination of whether to
accept the applicant for credit occurs in real time.
5. A computer readable medium having program code embodied therein
for providing approval of credit over a network, which, when read
by a computer, causes the computer to perform a process, the
program code comprising: program code for receiving via a computer
network applicant data from an applicant for a credit application;
program code for determining, prior to obtaining credit report data
from a credit bureau for the credit application, compliance of the
applicant data with one or more one or more requirements, the one
or more requirements comprising a duplicate check comprising
comparing automatically one or more elements of the applicant data
with data previously submitted by applicants; program code for
declining approval for credit to the applicant if the applicant
data fails to meet one or more of the one or more requirements;
program code for, if the applicant is not declined: processing
automatically one or more elements of the applicant data into a
predetermined electronic form; electronically transmitting the one
or more elements of applicant data in the predetermined electronic
form to a credit bureau for obtaining a credit report from a credit
bureau for the applicant; receiving electronically a credit report
having credit report data from a credit bureau for the applicant;
and determining automatically, without intervention of a human,
whether to accept or reject the applicant for credit based at least
in part on the credit report data; and program code for
communicating, if it is determined to accept the applicant for
credit, to the applicant that the applicant has been approved for
credit.
6. A computer system, the computer system comprising: means for
receiving via a computer network applicant data from an applicant
for a credit application; means for determining, prior to obtaining
a credit report from a credit bureau for the credit application,
compliance of the applicant with one or more requirements, the
means for determining compliance with one or more requirements
including means for determining whether applicant has previously
made application for credit within a predetermined period of time;
means for processing automatically, if the applicant is in
compliance with the one or more requirements, one or more elements
of the applicant data into a predetermined electronic form and
automatically electronically transmitting to a credit bureau for
obtaining a credit report from a credit bureau for the applicant;
means for receiving electronically a credit report having credit
report data from a credit bureau for the applicant; decision means
for determining, without intervention of a human, whether to accept
or reject the applicant for credit based at least in part on the
credit report data; and means for communicating automatically with
the applicant the determination of the decision means.
7. The computer system of claim 6, wherein the decisions means
makes the determination in real time.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation of U.S. patent
application Ser. No. 10/782,311," filed Feb. 18, 2004, which is a
continuation of U.S. patent application Ser. No. 09/595,556, filed
Jun. 15, 2000, now U.S. Pat. No. 6,718,313, which is a
continuation-in-part of U.S. patent application Ser. No.
09/185,201, filed Nov. 3, 1998, now U.S. Pat. No. 6,405,181, and of
U.S. patent application Ser. No. 09/858,878, now U.S. Pat. No.
6,567,791, all of which are herein incorporated by reference.
TECHNICAL FIELD OF THE INVENTION
[0002] The present invention relates generally to electronic
commerce. More specifically, the invention relates to methods and
apparatuses for providing real time credit approval to an applicant
online by obtaining data from an applicant, verifying and
formatting the data so obtained in a manner that permits accessing
the applicant's credit report, and making an underwriting decision
to grant or deny credit to the applicant in real time based on data
from one or more credit bureau reports.
BACKGROUND
[0003] With the advent of electronic commerce on the Internet,
applicants have begun to expect decisions that have historically
required a period of days or weeks to be made instantly when
processed on line. Numerous transactions such as purchases of
consumer goods, airline tickets, and movie tickets have been
adapted for execution on line in a matter of seconds. What has not
been perfected is the ability to make a credit decision and grant
credit to a party on line in real time. (For the purpose of this
specification, "instant" or "real time" credit means within a short
period of time within less than about five minutes.) As a result,
virtually all Internet commerce to date requires some previously
secured method of payment such as a credit card obtained by
conventional means or other previously ananged payment source such
as a bank account or electronic money.
[0004] One factor that has prevented Internet applicants from
providing information and receiving instant approval for credit is
the difficulty of interfacing with the various credit bureau
databases (Equifax, Trans Union, and Experian). Personal
information must be entered by a party authorized by the credit
bureaus to communicate with the credit bureaus for the purpose of
accessing credit bureau reports. Such information must be in
exactly the correct form in order for an individual's credit report
to be retrieved. Another difficulty has been that the decision to
grant credit carries with it significant risk and systems have not
been successfully designed that can make a sufficiently reliable
underwriting decision using data provided directly by an applicant.
Many credit card issuers provide applications on line that may be
filled out by applicants. However, data from those applications
must be entered manually into the credit card issuer's system for
processing before a credit report is obtained and an underwriting
decision can be made. Other applicants may be preapproved by an
existing card issuer's system before an offer is made and accepted
online. However, the underwriting process has not been sufficiently
automated to allow a credit decision to be made in real time for an
applicant who has entered personal data into an application
system.
[0005] What is needed is a system and method for obtaining personal
data from a credit applicant, parsing the data into a format that
is compatible with that used by the credit bureaus, obtaining
credit bureau information and making an underwriting decision in
real time. Such a system would be useful for conveniently obtaining
a credit card on line. Automation of a process for obtaining a
credit report and making
[0006] an underwriting decision without human intervention would be
beneficial because credit approval decisions could be made faster
and more cheaply. The true power of such a system would be realized
when the system is accessed in the midst of a transaction to obtain
credit specifically for the purpose of that transaction.
SUMMARY
[0007] The present invention provides a system and method for
obtaining information from an applicant, accessing credit bureau
information and making a real time underwriting decision to accept
or reject the applicant. A parsing engine parses the information
provided by the applicant so that it may be sent directly to a
credit bureau. Information obtained from one or more credit bureaus
is used by an underwriter engine to make a decision whether to
grant credit to the applicant. It should be appreciated that the
present invention can be implemented in numerous ways, including as
a process, an apparatus, a system, a device, a method, or a
computer readable medium. Several inventive embodiments of the
present invention are described below. In one embodiment, a method
of providing real time approval of credit over a network is
disclosed. The method includes obtaining applicant data from an
applicant. The applicant data is analyzed into a form suitable for
directly obtaining a credit report from a credit bureau for the
applicant. A credit report having credit report data is obtained
from a credit bureau for the applicant. It is then determined
whether to accept the applicant using the credit report data and it
is communicated to the applicant that the applicant has been
approved. These and other features and advantages of the present
invention will be presented in more detail in the following
specification of the invention and the accompanying figures which
illustrate by way of example the principles of the invention.
BRIEF DESCRIPTION OF THE DRAWINGS
[0008] The present invention will be readily understood by the
following detailed description in conjunction with the accompanying
drawings, wherein like reference numerals designate like structural
elements, and in which:
[0009] FIG. 1 is a block diagram illustrating a preferred
architecture for a system that provides instant on-line credit card
approval.
[0010] FIG. 2 is a block diagram illustrating an application data
structure that is used in one embodiment to store the data
contained in an application and to keep track of the status of the
application as it progresses through the various modules described
in FIG. 1.
[0011] FIG. 3 is a flow chart illustrating the general process flow
through the modules of FIG. 1.
[0012] FIG. 4A is a flow chart illustrating a validation process
that is used in step according to one embodiment of the
invention.
[0013] FIG. 4B is a flow chart illustrating a process for parsing
an address entered by an applicant.
[0014] FIG. 5 is a flow chart illustrating a pre-credit bureau test
performed in one embodiment of the invention.
[0015] FIG. 6A is a flow chart illustrating a process for making an
underwriting decision using multiple credit reports.
[0016] FIG. 6B is a flow chart illustrating a process implemented
on the Underwriter for using credit bureau data to accept or reject
an applicant in one embodiment.
[0017] FIG. 6C is a flow chart illustrating a process for using the
FICO score combined with other attributes to accept or reject an
applicant.
[0018] FIG. 7 is a flow chart illustrating a process for checking
the status of an application and executing either an offer process
or one of several rejection processes.
[0019] FIG. 8A is a flow chart illustrating a process for
determining an appropriate reason to display for rejecting an
applicant and displaying that reason.
[0020] FIG. 8B is a diagram illustrating one data structure used to
map main FICO factors provided by the credit bureau (referred to as
external codes) to internal decline codes as well as reasons for
rejection to be provided to rejected applicants.
[0021] FIG. 9 is a flow chart illustrating how a rejection reason
may be obtained.
[0022] FIG. 10A is a flowchart illustrating a process for providing
a set of multiple offers to an applicant and receiving a balance
transfer amount corresponding to an offer selected by the
applicant.
[0023] FIG. 10B is a flow chart illustrating one such method of
deriving a credit limit for an applicant based on the applicant's
FICO score and income, as well as the amount of total revolving
balance that the applicant elects to transfer.
[0024] FIG. 11 is another data representation illustrating another
embodiment of how the offers may be determined based on FICO score,
income range, income, and total revolving balance transfer.
[0025] FIG. 12 is a diagram illustrating a display provided to the
applicant for the purpose of presenting multiple offers to the
applicant.
[0026] FIG. 13 is a flow chart illustrating a process for obtaining
a real-time balance transfer from an applicant.
[0027] FIG. 14 is a block diagram illustrating one computer network
scheme that may be used to implement the system described
herein.
[0028] FIG. 15 is a block diagram illustrating a system for
providing real time chat help to an applicant and generating a
counter offer when appropriate.
[0029] FIG. 16 is a flowchart illustrating a general process
implemented on the chat server.
[0030] FIG. 17 is a flow chart illustrating a general process
implemented on the web server for sending dynamic web pages to the
applicant.
[0031] FIG. 18 is a flow chart illustrating a process implemented
on a browser for establishing a connection to a chat server.
[0032] FIG. 19 is a flowchart illustrating a typical process
implemented on the browser for the purpose of initializing chat
when the user does not respond to a downloaded web page in a
certain period of time.
[0033] FIG. 20 is a flow chart illustrating a process implemented
on a chat server when a chat session is requested by a browser as
described above.
[0034] FIG. 21A is a flow chart illustrating a process implemented
at a customer service agent for the purpose of supporting the chat
session.
[0035] FIG. 21B is a screen shot illustrating a display of offer
terms used in one embodiment for determining which terms are
unacceptable.
[0036] FIG. 22 is a flow chart illustrating in detail a process
implemented in step 712 for obtaining the unacceptable terms of an
offer from an applicant.
[0037] FIG. 23 is a flow chart illustrating the process implemented
on the counter offer server when more than one term is selected as
being unacceptable to the applicant.
[0038] FIG. 24 is a flow chart illustrating an example process for
generating a counter offer.
[0039] FIG. 25 is a flowchart illustrating a process implemented on
a counter offer server to generate and confirm a new offer for
display to the applicant.
[0040] FIG. 26 is a flowchart illustrating a process implemented on
the web server portion of the application server for the purpose of
displaying a new counter offer to the applicant.
[0041] FIG. 27 is a flow chart illustrating a process used in one
embodiment to automatically generate a refresh on the applicant's
browser.
DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS
[0042] Reference will now be made in detail to the preferred
embodiment of the invention. An example of the preferred embodiment
is illustrated in the accompanying drawings. While the invention
will be described in conjunction with that preferred embodiment, it
will be understood that it is not intended to limit the invention
to one preferred embodiment. On the contrary, it is intended to
cover alternatives, modifications, and equivalents as may be
included within the spirit and scope of the invention as defined by
the appended claims. In the following description, numerous
specific details are set forth in order to provide a thorough
understanding of the present invention. The present invention may
be practiced without some or all of these specific details. In
other instances, well known process operations have not been
described in detail in order not to unnecessarily obscure the
present invention.
[0043] FIG. 1 is a block diagram illustrating a preferred
architecture 102 for a system that provides instant on-line credit
card approval. As shown, an application engine 104 creates an
application by prompting an applicant for data and storing the
entered data. In one embodiment, the application engine creates an
application by communicating with the applicant over the World Wide
Web using Java, html or other commonly used Internet protocols. In
other embodiments, other types of connections may be established
between the applicant and the application engine. The application
includes applicant data such as the applicant's address and social
security number. Once created, the application is received by the
parsing engine 106 which parses an applicant's name and address and
creates appropriate software objects.
[0044] The parsing engine 106 parses the data into an exact format
that may be used to directly access credit bureau data. The
applicant is given an opportunity to view how the data submitted
has been parsed and to make corrections to parsed data, if
necessary. The parsing engine 106 is described in further detail in
FIG. 4B. The parsed data is passed to a Validator 108. Validator
108 validates certain data entered by the applicant such as the
social security number and zip code. Validation may include
checking either the form of a number to ensure that the correct
number of digits have been entered or checking content such as
checking that the area code portion of a phone number is a valid
area code or checking that a zip code matches a city. If the data
is determined to be valid, then the validated data is input to an
Underwriter 110. It is important to avoid sending invalid data to
the Underwriter to avoid the cost of requesting credit reports that
cannot be used.
[0045] Underwriter 110 receives data from the parsing engine and
evaluates the data to determine if the applicant should receive an
offer for credit. In one embodiment, the Underwriter sends the
parsed data to at least two credit bureaus, receives data from the
credit bureaus, and makes an underwriting decision based on an
analysis of the credit bureau data. The analysis may include, but
is not limited to, comparing the applicant's Fair Isaac Risk Score
(FICO score) to certain thresholds. Underwriter 110 is described in
further detail in FIGS. 6A and 6B. If the Underwriter determines
that an offer of credit should be extended to the applicant, then
an offer is made in real time to the applicant. As is described
below, the offer may include one or more sets of alternative terms
and those terms may be conditioned on the applicant taking certain
actions such as transferring balances. The applicant may be
required to actually take such actions in real time before an offer
conditioned on such actions is confirmed. If the Underwriter
determines that no offer of credit should be extended, then the
Underwriter determines a reason for rejecting the applicant.
[0046] Whether an offer is extended and accepted or not,
information about the offer or the rejection is passed to a
creditor module 112 that finalizes the offer and builds a data file
that is in the proper form to be sent to First Data Resources, Inc.
(FDR), or another such entity that provides a similar service to
FDR's service. During the finalization of the offer, FDR data is
built for all approved and declined applications. FDR handles the
embossing of the card and delivering it to approved applicants. FDR
also handles sending rejection letters to rejected applicants.
[0047] If, at any time during the process, a system error occurs
that interrupts the process, then an application object loader 114
loads the appropriate application for reentry into the system. It
should be noted that in one embodiment, the data that is processed
and stored by each module is stored as an application object as is
described further in FIG. 2. In other embodiments, the data is
stored in other ways, such as in a table or in a database.
[0048] FIG. 2 is a block diagram illustrating an application data
structure 202 that is used in one embodiment to store the data
contained in an application and to keep track of the status of the
application as it progresses through the various modules described
in FIG. 1. It should be noted that other data structures may be
used in other embodiments within the scope of this invention.
Application data structure 202 includes an application object 204
that is created by the application engine. Application object 204
points to a number of associated data structures, including an
applicant object 206. Applicant object 206 stores applicant data
and includes one or more data elements 208. For example, an
applicant data element 208 may include information such as the
applicant's address, phone number, or social security number. The
application data structure also includes one or more test result
objects 210. Each test result object 210 stores a validation status
212 associated with a validation test applied to the data
associated with applicant object 206. For example, a test result
object may include a social security number status indicating
whether the social security number entered by the applicant is a
valid social security number. Also, a test result object 210 may
include a zip code status indicating whether the zip code entered
by the applicant matches the rest of the address entered by the
applicant. Test result objects are used to check whether data
entered by the applicant is valid before certain actions are taken,
such as a credit report being ordered.
[0049] The application data structure further includes a set of
credit report objects 214 associated with each credit report
ordered. In one embodiment, the Underwriter requires at least two
credit reports from two of three credit bureaus before a decision
to grant credit is made. This rule effectively enables a real time
credit decision to be made without incurring an unacceptable amount
of risk. Since credit reports are preferably ordered from more than
one credit bureau, the application data structure will likely
include several credit report objects. Each credit report object
214 includes a plurality of attributes 216. An attribute is an item
of data provided by the credit bureau in the credit report. For
example, one such attribute is a 90 day attribute that indicates
the number of times that the applicant has been more than 90 days
late in payment of a debt. Similarly, a 60 day attribute may be
provided. Other attributes may include a FICO score, the number of
times the applicant has been severely delinquent, existence of a
derogatory public record, whether the applicant is now delinquent,
the applicant's total revolving balance, and the amount of time
that a credit report has been on file for the applicant (also
referred to as "thickness of file" or "time on file."
[0050] As is described below, in one embodiment, the Underwriter
bases its decision on the FICO score alone when the FICO score is
below a rejection threshold. In some embodiments, there may be
automatic approval when the FICO score is above an approval
threshold.
[0051] The application data structure further includes FDR data
object 218 associated with the application. FDR data is created by
the creditor module for the purpose of sending application
information to FDR so that FDR may send credit cards to successful
applicants and send rejections to unsuccessful applicants, when
that is required.
[0052] The application object also includes a status object 220.
The status of the application object is determined at various times
by the modules. For example, the Validator module may determine
that the application is invalid based on an invalid social security
number or zip code. The Underwriter module may also determine that
the application is a duplicate, as will be described below. The
Underwriter may also change the status of an application to
accepted or declined. In addition, certain applications may be
tagged with a fraud status flag indicating that there is a
likelihood of fraud. The application data structure also may
include a set of offers 222 to be provided to the applicant.
[0053] Thus far, the software architecture and data structure used
to make a real time credit decision in one embodiment have been
described. Next, the processes implemented in the modules will be
described.
[0054] FIG. 3 is a flow chart illustrating the general process flow
through the modules of FIG. 1. The process starts at 300. In a step
304, applicant data is obtained via html, Java or other suitable
network protocol. It should be noted that in different embodiments,
the information entered by the applicant may be either parsed first
by the parsing engine or validated first by the Validator. For the
purpose of illustrating this point, FIG. 3 shows Validation
occurring first in a step 306. FIG. 1 alternatively shows the
parsing engine operating first. If the information is not valid,
then control is transferred from a step 308 to a step 309 and the
applicant is given an opportunity to edit the data. The Validator
then rechecks the edited data.
[0055] If the information is valid, then control is transferred to
a step 310 where the data entered is displayed along with the field
assigned to each part of the data by the parsing engine. This step
is important to ensure that the data will be readable when it is
sent to a credit bureau by the Underwriter. An exact match is
required by the credit bureaus for the correct credit report to be
sent. Various ambiguities in the way that an address may be
expressed can cause difficulties. Such difficulties have been a
significant factor in preventing other systems from allowing
individuals to directly access credit bureau data. For example, it
is necessary to distinguish a street direction that is part of a
street address from a street name that happens to be a direction,
such as "North."
[0056] To make certain that such distinctions as well as other
distinctions are made correctly, the parsing engine categorizes
each part of the entered address and presents the field names along
with that portion of the address that it has assigned to each field
name. So, for example, the applicant can move "North" from a street
direction field to a street name field if that is appropriate.
Thus, by parsing the address and assigning the different parts to
fields and then allowing the applicant to check and edit the
assignment, the parsing engine enables applicants with no knowledge
of the Byzantine structure required by the credit bureaus to enter
personal data in a manner that allows a credit report to be
obtained without human intervention. Initial parsing is achieved by
analyzing the form of the address and dividing, for example, the
street number, street name, city and state. However, regardless of
the care taken in designing initial parsing, some miscategorization
will likely occur. Displaying the parsing to the applicant and
allowing the applicant to correct parsing errors enables the
imperfect output of the parsing engine to be corrected. At the same
time, the process is much more user friendly and less tedious for
the user than if the user had been asked to enter each field that
the address is divided into by the parsing engine separately. By
having the parsing engine parse the address and present the result
of the parsing to the user, tedium is minimized and accuracy is
achieved.
[0057] If the applicant responds that the data and parsing is
correct instead of editing the parsing of the data into the
displayed fields in step 310, then a step 311 transfers control to
a step 312 where pre-credit bureau tests are run on the data. If
the applicant edits the data, then control is transferred back to
step 306 and the data is re-checked for validity. If the applicant
fails the pre-credit bureau test, then the applicant's status is
changed to rejected in a step 313 and if the applicant passes the
pre-credit bureau test, then the credit bureaus are accessed and
credit bureau tests based on the data obtained from the credit
bureau and other applicant data are performed in a step 314. If the
applicant passes the credit bureau tests, then post credit bureau
tests are run in a step 316. If the applicant passes the post
credit bureau tests, then the applicant is accepted to receive an
offer for credit and the approval process ends at 320.
[0058] If the applicant fails the credit bureau tests, then the
application status is changed to rejected in a step 315. As
described below, an on line rejection process is executed for
applications with a rejected status. Thus, the applicant
information is input to a series of tests and the result of the
tests determines whether the applicant is accepted or rejected.
[0059] FIG. 4A is a flow chart illustrating a validation process
that is used in step 306 according to one embodiment of the
invention. The Validator performs a plurality of validation tests
on the applicant data. The process starts at 400. In a step 402,
the applicant's address is validated according to an address
validation test. In one embodiment, address validation includes
checking that a street number and street name are entered and not a
P0 box. Next, in a step 404, a validation status associated with
the address validation test is stored in a test result object. In a
step 406, the applicant's phone number is validated according to a
phone number validation test. The phone number validation test may
include checking the number versus one or more tables or checking
that an appropriate number of digits are provided. In a step 408, a
validation status associated with the phone number validation test
is stored in a test result object. Finally, in a step 410, the
applicant's social security number is validated according to a
social security number validation test. In a step 412, a validation
status associated with the social security number validation test
is stored in a test result object and the process ends at 420.
[0060] In this manner, the form of the data entered by the
applicant is checked to determine whether the data entered is at
least potentially correct. For example, if a social security number
that does not exist for anyone is entered, it can be determined
that the entered data must be invalid. In other embodiments,
additional validation tests may be performed. Specifically,
validation tests that help detect fraud may be implemented. In one
embodiment, the validation status associated with each test result
object includes a time stamp. Multiple applications with the same
or similar names may be tracked and a history may be saved. Fraud
tests may be implemented that track the number of applications
submitted by a given individual and check the consistency of
applicant data between multiple submitted applications.
[0061] FIG. 4B is a flow chart illustrating a process for parsing
an address entered by an applicant. The process starts at 450. In a
step 452, the address is split into fields using a parser. Next, In
a step 454, the parsing result is displayed. The applicant is
prompted to indicate whether or not the parsing result is correct
in a step 456. If the result is not correct, then control is
transferred to a step 458 and the applicant is allowed to change
the fields assigned to each part of the data. Once the parsing is
approved by the applicant, control is transferred to a step 460 and
the parsed data is sent to the Underwriter. It should be noted that
the data may also be sent through the Validator again if the data
was changed by the user. The process ends at 462.
[0062] FIG. 5 is a flow chart illustrating a pre-credit bureau test
performed in step 312 in one embodiment of the invention.
Pre-credit bureau tests are performed prior to obtaining one or
more credit reports for the applicant for the purpose of avoiding
the expense of obtaining a credit report for certain applicants who
would not be approved regardless of the content of the credit
report. For an example, an applicant could be rejected based the
applicant being of a minor age. In one embodiment, the pre-credit
bureau test is performed by the Underwriter. In other embodiments,
the pre-credit bureau test may be performed by the parsing engine
or a separate module. The process starts at 500. In a step 502, the
applicant's income is obtained. Next, at step 504, it is determined
if the applicant's income exceeds an annual income criteria. If the
applicant does not meet the annual income criteria, the status of
the application may be set to declined in a step 506. By way of
example, if the income entered by the applicant is less than
$15,000, the status of the application maybe set to declined. In a
step 508, the applicant's age is obtained. In a step 510, the
applicant is verified to meet a minimum age criteria. For example,
the minimum age may be 18. If the applicant fails to meet the
minimum age criteria, the application status may similarly be set
to declined in a step 512. It should be noted that the above
description recites that age and income are checked in separate
steps. Alternatively, they may be checked together.
[0063] If the applicant meets the minimum age and income
requirements, then control is transferred to a step 514. Step 514
checks whether the application entered is a duplicate application.
If the applicant has previously entered the information in the
application database, then the current application is a duplicate
application. It is important to recognize such duplicate
applications so that a single applicant cannot require multiple
credit reports to be obtained. In one embodiment, duplicate
applications are recognized by checking for duplicate social
security numbers, duplicate names and/or duplicate addresses. In
order to be rejected by the system, an application must match two
of the three criteria. A rule is established that an applicant may
reapply for a credit card after a specified time period has elapsed
(e.g., 60 days). Such a rule is implemented in a step 516 that
checks whether the application submission date exceeds a specified
time period since the submission date of the found duplicate
application. If the application is submitted prior to the specified
time period, the status of the application is changed to duplicate
in a step 518 and the process ends at 520.
[0064] When a duplicate application is submitted, then the
applicant is notified and a message is provided that informs the
applicants that duplicate applications may not be submitted within
a certain time period of each other. In addition, the applicant may
also be prompted to go to a re-entry screen that allows the found
duplicate application to be processed if processing of that
application was previously interrupted. In this manner, if an
applicant quit in the middle of the application process, then the
application process can be completed for the previously submitted
application.
[0065] It should be noted that a specific series of pre-credit
bureau tests have been shown for the purpose of illustration. Other
tests can be used within the scope of this invention. Also, it
should be noted that if one test is failed, then remaining tests
are skipped in some embodiments. Alternatively, all of the
pre-credit bureau tests may be performed and the pre-credit bureau
test results may be stored in separate question objects. This may
help detect potentially fraudulent applicants who create many
duplicates. If an application is determined potentially to be
fraudulent, the status of the application is changed to fraud.
Alternatively a separate flag may be set to indicate the potential
fraud.
[0066] Once it is determined the applicant has entered data that is
at least potentially valid and the applicant has approved the
output of the parsing engine, the application is ready to be
checked by the Underwriter to determine whether credit should be
approved for the applicant. The Underwriter makes such a
determination based on the information obtained from credit
bureaus. Since the decision made by the Underwriter is made without
human intervention, it is particularly important that the method of
determination made by the Underwriter is reliable. For this reason,
it is preferred that, in order for an applicant to be approved, at
least two credit bureaus must provide information about that
applicant that passes a series of tests. In some embodiments, this
rule may be relaxed, but a process that requires data from at least
two credit bureaus for approval has been shown to have superior
reliability to processes without such a requirement. In particular,
it has been determined that requiring data from at least two credit
bureaus for approval is an important factor in enabling the real
time credit approval system to make sufficiently reliable
determinations.
[0067] Because at least two credit reports from two different
credit bureaus are required, it is possible that certain applicants
may be rejected because they are only included in the records of a
single credit bureau. When this occurs, that reason for rejection
is given to the applicant instead of a reason based on the failure
of the applicant to pass a test based on credit bureau data.
[0068] FIG. 6A is a flow chart illustrating a process for making an
underwriting decision using multiple credit reports. The process
starts at 600. In a step 602, a first credit bureau test is
performed. The process of performing a test on individual credit
bureau data is further described in FIG. 6B. If that test is
failed, then the application is rejected in a step 604 and the
process ends at 606. Immediately rejecting the application after a
first failure saves the cost of obtaining a second credit bureau
report. If the first credit bureau test does not fail, either
because no report is obtained or because the test is passed, then
control is transferred to a step 608 and a second credit bureau
test is performed. If that test is failed, then the application is
rejected in step 604 and the process ends at 606. If the second
credit bureau test does not fail, then it is determined in a step
612 whether two credit bureau tests have been passed. If two tests
have been passed, then the application is accepted in a step 614
and an offer is determined as described below.
[0069] If two credit bureau tests have not been passed, then
control is transferred to a step 616 where it is determined whether
one credit bureau test has been passed. If one credit bureau test
has not been passed, then the application is rejected in a step 618
for not having a record in at least two credit bureaus. The third
credit bureau is not checked since it is not possible to get at
least two credit reports at that point. If one credit bureau test
has been passed, then a third credit bureau is consulted in a step
620. If the third credit bureau test is failed, then the
application is rejected in a step 622 and the process ends at 606.
If the third credit bureau report does not have a record for the
applicant, then the application is rejected in step 618 for not
having enough credit records and the process ends at 606. If the
third credit bureau test is passed, then the application is
accepted in a step 624 and the process ends at 606.
[0070] Thus, the Underwriter only accepts applications that pass at
least two credit bureau tests. It should be noted that a special
reason for rejection may be given to applicants who are rejected
because they do not have a record in at least two credit bureaus.
Also, it should be noted that in some embodiments, it is
distinguished whether a credit report is not obtained because a
credit bureau is temporarily unavailable or whether a credit report
is not obtained because there is no record for the applicant. In
the event that a credit bureau is unavailable, an applicant that
cannot be found in the remaining two credit bureaus may be given a
special rejection notice indicating that a later attempt should be
made by the applicant when the unavailable credit bureau is
functioning. Also, when two credit bureaus are unavailable at the
same time, all applicants may be requested to reapply when the
credit bureaus return on line.
[0071] FIG. 6B is a flow chart illustrating a process implemented
on the Underwriter for using credit bureau data to accept or reject
an applicant in one embodiment. The process starts at 650. In a
step 652, a credit report is requested from the credit bureau. As
described above, the credit report can be requested using data
entered directly by the applicant because the parsing engine
classifies the data into appropriate fields to be sent to the
credit bureau. Once the report is received, the Underwriter
performs tests on the data in the credit report. Data entered by
the applicant may be used for Underwriter tests as well. In a step
656, a set of attribute tests are performed using the credit
report. Attribute tests are general tests that may be applied to
any credit report. Each attribute test corresponds to a general
attribute provided in the credit report. Attribute tests may
include threshold tests, which compare certain parameters such as a
FICO score to a threshold, or logical tests, which check for the
existence of certain adverse records. Next, in a step 658, a set of
credit report specific tests are performed using the credit report.
A set of credit report specific tests may be defined for each
credit bureau. Each credit report specific test corresponds to data
that is specific to a particular credit bureau.
[0072] The credit bureau tests may be separately performed to avoid
performing the remaining tests once the failure of the application
to pass a test results in a determination that the application will
be declined. However, each of the set of attribute tests and credit
report specific tests are preferably performed so that the best
basis for rejection may be identified and provided to the
applicant. Determining an appropriate basis of rejection to display
to the applicant is described further below in connection with FIG.
7. It is determined in a step 660 whether the applicant passed the
credit tests and the application is rejected in a step 662 if the
applicant failed the tests. If the applicant passes the tests, that
is noted in a step 664 for the purpose of determining whether the
applicant should be accepted as described in FIG. 6A. The process
then ends at 670.
[0073] As described above, the process of performing the various
tests may generally be considered as performing various attribute
tests and credit specific tests and combining the results of those
tests in some fashion to make a decision to pass or fail an
applicant.
[0074] FIG. 6C is a flow chart illustrating a process for using the
FICO score combined with other attributes to accept or reject an
applicant. The process starts at 680. In a step 682, the FICO score
is checked. If the FICO score is below a rejection threshold, then
the application is rejected in a step 684. If the FICO score is
above an acceptance threshold, then control is transferred to a
step 688 and other attributes are checked. If any attribute tests
are failed, then control is transferred to step 688 by a step 690
and the application is rejected. If all attribute tests are passed,
then control is transferred to a step 692 and the application is
accepted. The process ends at 694.
[0075] It should be noted that in other embodiments, other methods
of determining whether to accept or reject an applicant are used.
For example, in one embodiment, an applicant is accepted
automatically if he or she has a FICO score that is above a certain
threshold.
[0076] The attribute tests performed in step 688 may take on
various forms. In one embodiment, a list of attributes is checked
including attributes such as whether the applicant is severely
delinquent, currently delinquent, has a derogatory public record,
or has been delinquent a certain number of times in a past period.
A test may be defined for each attribute such as a maximum number
of times delinquent above which the test is failed. In one
embodiment, a list of tests is defined and all of the tests must be
passed. In another embodiment, a list of tests is defined and
certain subsets of the list are also defined. At least one subset
must be passed for the applicant to pass.
[0077] Once the decision is made to accept or reject an applicant,
the status of the applicant is set to be accepted or rejected.
Rejected applications are processed in a rejection process
described in FIG. 7. Accepted applications are processed in an
offer and confirmation process described in FIG. 10A.
[0078] FIG. 7 is a flow chart illustrating a process for checking
the status of an application and executing either an offer process
or one of several rejection processes. The process starts at 700.
In a step 702, the status of the application is checked based on
the processing performed by the Underwriter. As mentioned above,
the Underwriter determines whether the application is a duplicate
application, whether enough credit bureaus are available to provide
sufficient credit reports to evaluate the application, and whether
applications having sufficient credit reports should be accepted or
rejected.
[0079] If the status of the application determined by the
Underwriter is that the application is a duplicate of a previously
entered application, then control is transferred to a step 706 and
a message indicating that the application is a duplicate is
displayed to the applicant. Next, in a step 708, a link to a
reentry screen is provided to the applicant. The reentry screen
allows the applicant to execute a process that finds the earlier
application and allows the applicant to review or resume the
earlier application. For example, if the earlier application was
accepted but the applicant did not accept an offer, then the
process may resume at that point and the applicant may be given
another opportunity to accept. This is preferable to allowing the
application process to be repeated from the beginning since that
could needlessly cause a new credit report to be obtained. After
the reentry screen is displayed, the process ends at 720.
[0080] If the status of the application indicates that the
application has been accepted, then control is transferred to a
step 714 and an offer process is executed. The offer process is
described in further detail in FIG. 10. If the status of the
application is that a credit bureau error occurred, then control is
transferred to a step 710 and an error message is displayed
indicating that not enough credit bureaus are currently available
to allow the application to be processed. Also, in a step 712, a
link is provided to a site that allows the applicant to report the
error and request further information or request to be contacted.
After the offer process or the credit bureau error process is
executed, the process ends at 720.
[0081] If the status of the application indicates that the
application has been rejected, then control is transferred to a
step 704 and a rejection process is executed. The rejection process
is described in further detail in FIG. 8A and FIG. 8B. Once the
rejection process is executed, the process ends at 720.
[0082] FIG. 8A is a flow chart illustrating a process for
determining an appropriate reason to display for rejecting an
applicant and displaying that reason. The process starts at 800. In
a step 802, the main factors given by the credit bureau that affect
the FICO score are obtained. Generally, the main factors identified
by the credit bureau for the FICO score are provided in the form of
a numerical code that corresponds to a predetermined factor. In a
step 804, the credit bureau code is mapped to an internal code that
is determined from a data structure that maps bureau codes to
internal factors. In one embodiment, the data structure is a table
such as that illustrated in FIG. 8B.
[0083] Certain credit bureau codes that indicate positive factors
that would be inappropriate bases for rejection such as home
ownership are mapped by the data structure to a general rejection
reason such as "Applicant rejected based on FICO score" or
"Applicant rejected based on credit bureau data." Although such
general reasons may be provided to the applicant as a last resort,
it is preferred that a more specific reason be given. To that end,
a step 806 checks whether any of the FICO reasons have been mapped
to any specific rejection reasons. If all of the FICO reasons map
only to the general reason, then control is transferred to a step
808.
[0084] In step 808, the rejection process begins to attempt to find
a more appropriate reason for rejection of the applicant. First,
the results of the various attribute tests generated by the
Underwriter are obtained. In a step 810, it is checked whether any
of the attribute test results map to an appropriate rejection
reason. If an attribute test result maps to an appropriate reason,
then control is transferred to a step 812 and the attribute reason
is assigned as the reason given to the applicant upon rejection. If
the attribute test does not map to an appropriate reason, then
control is transferred to a step 816 and a general reason is
assigned as the reason given to the applicant upon rejection. If,
in step 806, it was determined that one or more of the FICO score
factors identified by the credit bureau correspond to an acceptable
rejection reason other than the general rejection reason, then that
reason is assigned as the reason to be given to the applicant in a
step 814. Whether or not a specific reason is identified by that
above mentioned steps, control is transferred to a step 818 where
the reason is displayed to the applicant and the process then ends
at 820.
[0085] FIG. 8B is a diagram illustrating one data structure used to
map main FICO factors provided by the credit bureau (referred to as
external codes) to internal decline codes as well as reasons for
rejection to be provided to rejected applicants. It should be noted
that although a table is shown, other data structures such as a
linked list are used in other embodiments. Each external code maps
to an internal code that corresponds to an internal reason for
rejecting the applicant. The actual reason is also stored for each
internal code. As described above, certain external codes
correspond to internal codes that provide only a general rejection
reason. Other external codes are mapped to internal codes that
allow a specific rejection reason to be given.
[0086] Once an appropriate rejection reason is selected, it is
necessary to display the reason to the applicant. In one
embodiment, the reason is displayed on a web page along with an
acknowledgement button that allows the applicant to acknowledge
that he or she has read the rejection message. FIG. 9 is a flow
chart illustrating how a rejection reason may be obtained. The
process starts at 900. In a step 902, the reason for rejection is
retrieved. Next, in a step 904, the rejection reason is displayed.
In addition, in a step 906, a link to a credit counseling site is
also displayed. The acknowledgement button is displayed in a step
908. When the applicant leaves the rejection page, a step 910
checks whether the acknowledgement button has been activated. If
the button has been activated, then control is transferred to a
step 912 where the application is marked as having had an
acknowledgement to a rejection. If the acknowledgement button has
not been activated, then control is transferred to a step 914 and
the application is marked as not having had an acknowledgement to a
rejection. The process ends at 916.
[0087] It should be noted that other methods of verifying that a
rejection has been received are used in other embodiments. For
example, in one embodiment, an applet is sent along with the
rejection that sends a message back to the credit approval system
when the rejection message page is completely downloaded by the
applicant. In this manner, the fact that a rejection was delivered
to the applicant can be verified without requiring any action by
the applicant.
[0088] Once the rejection has been sent and acknowledged or not,
the rejection or acknowledgement status may be provided to an
entity such as FDR for the purpose of generating hard copies of
rejection letters and either sending such hard copies as
confirmations to all rejected applicants or else, in some
embodiments, only sending hard copies of rejection letters to
applicants that have not acknowledged an on line rejection.
[0089] Accepted applications have an accepted status and they also
contain important applicant information supplied by the applicant
and obtained from the credit bureau reports that can be used to
design a custom account level offer for the applicant. Preferably,
multiple offers are presented to the applicant, allowing the
applicant to select an offer that includes terms that the applicant
desires to accept.
[0090] FIG. 10A is a flowchart illustrating a process for providing
a set of multiple offers to an applicant and receiving a balance
transfer amount corresponding to an offer selected by the
applicant. The process starts at 1000. In the step 1002, the
application object is retrieved. The application object includes
the information provided by the applicant as well as information
obtained from credit bureaus and analyzed by the Underwriter.
[0091] Next, in a step 1004, offer selection criteria are obtained
from the credit report object. In one embodiment, the offer
selection criteria include FICO score, income and a balance
transfer requirement. Offer selection criteria also may include
data entered by the applicant. The offer selection criteria also
may include other attributes such as time on file. In general, the
offer selection criteria are selected from information obtained
from the applicant and from the credit bureaus for the purpose of
estimating the applicant's risk of default to determine an
expectation of future loss as well as an expected future total
revolving balance (TRB). In this manner, an appropriate offer may
be determined. In one embodiment, the balance transfer requirement
is calculated as a selected percentage of the applicant's TRB. As
described below, different offer terms may be provided for
different balance transfer requirements. As noted above, in other
embodiments, other data structures than the application object are
used to store this information.
[0092] Next, in a step 1006, a set of offers is derived from the
credit report data and other applicant information stored in the
application object. In a step 1008, the set of offers is displayed.
In one embodiment, the offers are derived from the FICO score and
income of the applicant, which determine the risk of default, and
also from a balance transfer amount specified in the offer. The
balance transfer amount may be determined as a percentage of the
total revolving balance that the applicant has on all outstanding
credit cards in the credit report for the applicant. Both the
credit limit offered to the applicant and the interest rate offered
to the applicant may vary according to the amount of the total
revolving balance that the applicant chooses to transfer to the new
account.
[0093] In addition offers may present incentives such as frequent
flier miles, cash back on purchases, or favorable interest
rates.
[0094] In a step 1010, the system notes the selected offer and
balance transfer amount. Next, in a step 1012, the system obtains
the balance transfer amount from the applicant. Preferably, the
balance transfer is actually executed while the applicant is on
line. The process for obtaining and executing the balance transfer
in real time on line is described further in FIG. 13. Once the
balance transfer is executed, a data file is assembled for
transmission to FDR for the purpose of issuing a credit card in a
step 1014. The process ends at 1016. Thus, the system derives a set
of offers based on information from the applicant's credit reports
and displays the set of offers to the applicant. The applicant then
can select an offer based on the amount of balance transfer that
the applicant wishes to make. Once the applicant selects an offer
and a balance transfer amount, the system actually executes the
balance transfer by allowing the applicant to select the accounts
from which to transfer balances. Once the balance transfer is
executed, the data relating the application is assembled and sent
to FDR.
[0095] In different embodiments, the system uses different methods
of determining the terms of the offer extended to the applicant
based on the information derived from the credit report. FIG. 10B
is a flow chart illustrating one such method of deriving a credit
limit for an applicant based on the applicant's FICO score and
income, as well as the amount of total revolving balance that the
applicant elects to transfer. The process starts at 1020. In a step
1022, the system obtains applicant information and the credit
bureau information. This information may include the FICO score and
income of the applicant. Next, applicant information and the credit
bureau information are used to determine an expected unit loss rate
for the applicant In a step 1024. The unit loss rate corresponds to
the probability that the applicant will default on the credit line
extended. That probability multiplied by the credit limit extended
to the applicant determines the dollar loss rate for that
applicant. The dollar loss rate divided by the average total
outstanding balance of the account is the dollar charge off rate
for the applicant.
[0096] In one embodiment it is desired that a dollar charge off
rate be kept within a determined range for different applicants. To
accomplish this, it is desirable to extend smaller amounts of
credit to applicants with a higher probability of defaulting. It is
also useful to extend different amounts of credit based on a total
outstanding balance transferred by the applicant since the balance
transfer influences the likely future total outstanding balance of
the account. Conventional offer systems have been able to extend
offers to applicants with credit limits that are controlled by the
applicant's predicted average dollar loss. However, prior systems
have not been able to extend credit and determine a credit limit
based on a predicted total outstanding balance for the client
because they have failed to be able to present offers and condition
the acceptance of the offers in real-time on a balance transfer
made by the applicant.
[0097] Next, in a step 1026 the system determines one or more
balance transfer amounts based on the total revolving balance that
the applicant has in various other credit card accounts. In one
embodiment, the balance transfer amounts are calculated based on
different percentages of the total revolving balance determined
from all of the applicant's accounts found in the credit report.
Then, in a step 1028, the system calculates for each total balance
transfer amount choice that will be presented to the applicant, a
predicted estimated revolving balance for the future that the
applicant would be expected to maintain. The estimated total
revolving balance may be equal to the balance transfer amount or
may be a function of the balance transfer amount. In one
embodiment, the estimated total revolving balance does not depend
on the balance transfer amount. In one embodiment, four possible
percentages of the applicant's total revolving balance as
determined by the credit report are presented to the applicant.
Those choices are none of the balance, one-third of the balance,
two-thirds of the balance, and the full balance. Depending on which
of those amounts is selected by the applicant, the system
calculates a predicted total revolving balance for the future.
Then, in a step 1030, the credit limit for the applicant is set to
achieve a target dollar charge off rate based on the amount of the
total revolving balance that the applicant elects to transfer and
the risk of default. The process then ends at 1032.
[0098] The process described in FIG. 10B shows conceptually how a
credit limit could be determined based on an amount of balance
transfer and a FICO score and income. This process may be
implemented directly in some embodiments. However, in other
embodiments, it is preferred that a table be precalculated that
includes amounts of credit limit that the applicant will be given
based on certain amounts of balance transfer and FICO score. Using
such a table, the applicant's FICO score and balance transfer
amount may be looked up and then the credit limit may be found in
the corresponding cell. FIG. 10C is a table illustrating how this
is accomplished. Each row of the table corresponds to a different
FICO score, and each column of the table corresponds to a different
balance transfer amount. When the cell corresponding to the FICO
score and balance transfer amount is determined, the credit limit
obtained. A cut-off line 1040 is also shown which represents an
upper limit for a balance transfers for a given FICO score.
[0099] In the embodiment described above, separate tables are
prepared for applicants of different incomes. In addition, separate
tables may also be prepared for applicants having other different
characteristics such as time on file for the applicant. It should
be noted that the tabular representation of the data is presented
as an example only and the data may be represented in many ways
including in three-dimensional or four-dimensional arrays, linked
lists or other data representations optimized for a particular
system. By allowing the account credit limit to be a function of
FICO score, balance transfer, and income, a credit limit may be
selected for each individual account that enables the dollar charge
off rate for all applicants to be controlled.
[0100] FIG. 11 is another data representation illustrating another
embodiment of how the offers may be determined based on FICO score,
income range, income, and total revolving balance transfer. A
single table includes a range of FICO scores 1108, an income range
1110, a balance transfer column 1112, and four offer columns, 1114,
1116, 1118, and 1120. Each of the offer columns includes a link to
a web page that describes the offer in more detail. Once the proper
row of the table is found, multiple offers may be displayed to the
applicant by assembling the various links either in a single frame
or in consecutive frames for the applicant to view and select an
offer.
[0101] Another component of the offer granted to the applicant that
may be varied based on the balance transfer selected is a teaser
rate or annual rate. A teaser rate is an interest rate that is
temporarily extended to the applicant either on the amount
transferred or on the amount transferred and purchases made for a
certain period of time. The teaser rate is intended to incent the
applicant to transfer a greater balance to a new account. In one
embodiment, the teaser rate is determined based on the percentage
of the applicant's total revolving balance that the applicant
elects to transfer. Thus, the amount transferred by the applicant
controls not only the applicant's credit limit but also determines
a teaser rate extended to the applicant.
[0102] FIG. 12 is a diagram illustrating a display provided to the
applicant for the purpose of presenting multiple offers to the
applicant. The display includes a first offer 1204, a second offer
1206, a third offer 1208, and a fourth offer 1210. For each offer,
there is a column 1214 corresponding to the initial teaser rate, a
column 1216 corresponding to the annual fee offer, a column 1218
corresponding to the credit limit, and a column 1220 corresponding
to the required balance transfer for that offer to be accepted. The
applicant selects one of the offers from the table. As noted above,
in one embodiment, the offers are provided as part of a web page
and the offers are presented using html. By selecting an offer, the
applicant selects a link that indicates to the system which offer
is selected. Once an offer is selected, the process of acquiring
the required balance transfer in real-time from the applicant is
executed. That process is described further in FIG. 13.
[0103] FIG. 13 is a flow chart illustrating a process for obtaining
a real-time balance transfer from an applicant. The process starts
at 1300. In a step 1302, the system retrieves the accounts and
balances that the applicant has based on the credit report data
obtained for the applicant. Next, in a step 1304, the estimated
balances for each of the accounts that were retrieved in step 1302
are presented to the applicant and the accounts are identified.
Identification of the accounts is a sensitive issue because the
specific account data for the applicant is confidential and if the
information is displayed to an unauthorized person, fraud could
result. Therefore, in one embodiment, a partial account number that
lists the account granting institution as well as part of the
account number for the account held by the applicant with that
institution is displayed. Generally, this information is sufficient
for the applicant to recognize the account, but is not enough
information to present a fraud risk.
[0104] It should be noted that in some embodiments, the accounts
chosen for display by the underwriter are selected in a manner to
facilitate a simpler balance transfer. For example, the largest
account balances may be displayed first so that amounts may be
efficiently transferred to meet the required transfer. Also, a
group of balances to transfer may be presented to the applicant by
highlighting certain accounts.
[0105] Next, the applicant is given an opportunity to indicate a
balance transfer by selecting one of the accounts and indicating
the amount to be transferred. It should be noted that the applicant
in this manner does not need to provide account information to
execute a balance transfer. If a transfer is indicated, control is
transferred to a step 1306 and the amount of the user balance
transfer is obtained. Next, in a step 1307, it is determined
whether the sum of the balance transfers is greater than or equal
to the required transfer amounts for the offer selected by the
applicant. If the amount is not greater than or equal to the
required-transferred amount, then control is transferred back to
step 1304 and the applicant is given an opportunity to select
further balances to transfer. If the amount of the balance
transfers is greater than or equal to a required transfer amount,
then control is transferred to a step 1308 and the system requests
final confirmation from the applicant of the balance transfers. If
it is determined in a step 1310 that a confirmation of the balance
transfer has been received, then control is transferred to a step
1312 and the balance transfers are executed. The process ends at
1314.
[0106] If in step 1304, it is determined that the applicant has
elected to exit the balance transfer screen instead of indicating a
balance transfer, or if it is determined in step 1310 that the
applicant elects not to confirm the balance transfer amounts
selected, then control is transferred to a step 1316 and the
applicant is returned to the offer selection screen so that the
applicant will have an opportunity to select another offer that
either does not require a balance transfer or requires less of a
balance transfer. The process then ends at 1314.
[0107] FIG. 14 is a block diagram illustrating one computer network
scheme that may be used to implement the system described herein.
An applicant host system 1402 is connected to the Internet 1404.
The applicant host system may be a PC, a network computer, or any
type of system that is able to transmit and receive information
over the Internet. Also, in other embodiments, a private network
such as a LAN or WAN or a dedicated network may be used by the
applicant to communicate. A web server 1406 is also connected to
the Internet and communicates with the applicant host system via
the Internet to request receive applicant information and to notify
the applicant of the results of the approval process. Web server
1406 in one embodiment accesses a business logic server 1408 that
implements the various approval checking processes described
herein. It should be noted that in some embodiments, the web server
and the business logic server are implemented on a single computer
system with one microprocessor. However, for the sake of
efficiency, the system implemented as shown is often used with
different servers dedicated to communicating with applicants and
processing applicant data, respectively. The business logic server,
wherever implemented, includes a communication line on which
communication may be had with credit bureaus or other outside data
sources. In some embodiments, an Internet connection may be used
for that purpose. Thus applicant data is obtained by the business
logic server either over the Internet either directly or through a
Web server. Also, data may be obtained by the business logic server
from an applicant using a direct dial in connection or some other
type of network connection.
[0108] A real time credit approval system has been described herein
primarily for the purpose of determining whether a credit card
should be issued to an applicant. Software written to implement the
system may be stored in some form of computer-readable medium, such
as memory or CD-ROM, or transmitted over a network via a carrier
wave in the form of Java.RTM. applets, other forms of applets or
servlets, and executed by a processor. The system may be
implemented on a PC or other general purpose computer known in the
computer art.
[0109] It should be recognized that the system described may also
be used for the purpose of granting credit to an applicant for the
purpose of making a single transaction. In such a system, a
transaction is interrupted and the application for credit is made.
Based on the real time approval decision made, credit may or may
not be granted for the purpose of completing the transaction.
[0110] Referring now to FIGS. 15-27, system for providing an
applicant with a counter offer of credit when the applicant rejects
a first offer is disclosed. In one embodiment, an applicant who
requests a counter offer is directed to a chat agent. The applicant
ID is transferred to the chat agent so the chat agent can access
information about the state of the applicant's application. Using
the chat interface, the applicant explains to the chat agent why
the original offer was not acceptable and the chat agent interacts
with an application database to determine a counter offer. The
counter offer is transferred to the applicant through an
application server.
[0111] In one embodiment, a method of offering credit to an
applicant includes determining a plurality of offers using
information about the applicant. A displayed offer is displayed and
a withheld offer is withheld. An indication that the displayed
offer is unacceptable is received and the withheld offer is
displayed.
[0112] In one embodiment, a method of offering credit to an
applicant includes determining a plurality of offers using
information about the applicant. A displayed offer is displayed and
a plurality of withheld offers are withheld. An indication that the
displayed offer is unacceptable is received including an indication
that an attribute is unacceptable. A selected withheld offer is
selected using the attribute that is unacceptable and the selected
withheld offer is displayed.
[0113] In one embodiment, a method of offering credit to an
applicant includes determining a plurality of offers using
information about the applicant. A displayed offer is displayed and
a plurality of withheld offers are withheld. An indication that the
displayed offer is unacceptable is received including an indication
that a plurality of attributes are unacceptable. A primary
unacceptable attribute is determined and a selected withheld offer
is selected using the primary unacceptable attribute. The selected
withheld offer is displayed.
[0114] In one embodiment, a method of offering credit to an
applicant includes determining an offer using information about the
applicant and displaying the offer to the applicant. An indication
that the displayed offer is unacceptable is received. An attribute
of the offer that is unacceptable is determined. In the event that
the unacceptable attribute is the amount of the credit limit; the
credit limit is recalculated for the applicant.
[0115] In one embodiment, a method of offering credit to an
applicant includes determining a first offer using information
about the applicant and displaying the first offer to the
applicant. A chat interface is activated between the applicant and
a customer service agent. A second offer for the applicant is
determined based on chat between the applicant and the customer
service agent and the second offer is displayed to the
applicant.
[0116] In one embodiment, an application server for providing a
counter offer of credit includes an applicant interface configured
to receive applicant data from an applicant browser and to
communicate an offer of credit to the applicant and the counter
offer of credit to the applicant. A processor is configured to
determine the offer of credit based on the applicant data and the
counter offer of credit based on an unacceptable attribute of the
first offer of credit and an agent interface is configured to
receive the unacceptable attribute from an agent.
[0117] In one embodiment, a chat server for providing a counter
offer of credit includes an applicant interface configured to
receive chat from an applicant. An agent interface is configured to
receive chat from an agent and an unacceptable attribute determined
from the chat from the applicant. An application server interface
is configured to send the unacceptable attribute and to receive a
counter offer.
[0118] In one embodiment, an applicant client for obtaining a
counter offer of credit includes an application server interface
configured to send applicant information and to receive and offer
of credit and a counter offer of credit. A chat server interface is
configured to be activated upon an indication that the offer of
credit is not acceptable.
[0119] In one embodiment, an applicant interacts with a web server
and receives a web page containing offers of credit that may be
accepted by the applicant. At any point during the interaction with
the web server, an online chat button or process may be activated
that sends an applicant ID to a chat server and opens a chat window
so that the applicant can receive help. In one embodiment, the help
takes the form of the applicant describing why a displayed offer is
unacceptable and a counter offer being generated for the
applicant.
[0120] FIG. 15 is a block diagram illustrating a system for
providing real time chat help to an applicant and generating a
counter offer when appropriate. A web server 1102 is in
communication with an application database 1103. Application
database 1103 is used to store information about the applicant and
the application. The information stored includes information
provided by the applicant as well as information derived from
various credit bureaus (not shown) that are accessed by the web
server either directly or indirectly. Each application included in
the application database is referenced by an applicant identifier
that can be used to identify the application.
[0121] Web server 1102 provides a web page 1104 to a browser 1106.
Typically, the web server and browser communicate over the Internet
using HTTP. Web page 1104 is shown for the purpose of illustration
as an offer web page that includes three offers made to the
applicant for a credit card as well as an on-line chat button that
may be activated by the applicant to obtain help or to discuss the
offers. Other web pages provided by the web server include forms
that the applicant fills out to provide information so that a
credit report may be obtained and an offer of credit generated
based on the applicant's personal information.
[0122] An online application process for a credit card is described
in detail in U.S. patent application Ser. No. 09/185,201, entitled:
"Method And Apparatus For Real Time Online Credit Approval", filed
Nov. 17, 1998, which was previously incorporated by reference; and
U.S. patent application Ser. No. 09/185,878, entitled: "Method And
Apparatus For A Verifiable Online Rejection Of An Applicant For
Credit", filed Nov. 17, 1998, which was previously incorporated by
reference; and U.S. patent application Ser. No. 09/185,000,
entitled: "Method And Apparatus For An Account Level Offer Of
Credit And Real Time Balance Transfer", filed Nov. 17, 1998 which
was previously incorporated by reference.
[0123] It should be noted that the process described herein will
refer to the online credit application as being an application for
a credit card. The process can also be applied to other offers of
credit including an offer of instant credit for the purpose of
consummating a single pending online transaction. In addition, the
system and processes disclosed herein may be applied to other types
of business transactions over the Internet. However, the particular
architecture and processes described are especially useful for
processing online credit card applications and the benefit of their
application to online credit card applications is particularly
strong.
[0124] Web server 1102 and browser 1106 continue to interact in a
standard fashion with web pages being provided by web server 1102
and the applicant filling out information as needed. At some point,
an applicant may activate the online chat button included on the
web page and a chat window 1104a opens up for the chat application
and a connection is established with a chat server 1108. As is
described further below, the chat window is opened and the
connection with chat server 1108 may be initiated by events other
than just the activation of the online chat button. Chat server
1108 implements a standard chat environment such as the chat
environment available from e-share. Other chat environments may be
used that include the ability to pass a variable to the chat server
from the browser.
[0125] The various servers shown in FIG. 15 may be implemented on
any typical platform such as a Windows NT platform, a Linux
platform, or other UNIX platform or other commercially available
web server platform. The browser may be implemented on any system
such as a Macintosh or a PC which are readily available.
[0126] In some embodiments, the chat process is initiated when the
applicant cancels out of the application. In other embodiments, the
chat process is initiated when the applicant lingers on a page for
an amount of time that exceeds a threshold. In other embodiments,
the chat process is initiated when the applicant's response to a
request for information is somehow inadequate. For example, it may
be detected that the answers provided by the applicant are
incomplete or in the wrong form. The chat process may be initiated
for the purpose of providing the applicant more detailed
instructions or pointing out to the applicant the information that
is required to complete the application.
[0127] In addition to opening the chat connection to chat server
1108, browser 1106 also sends the applicant identifier to the chat
server. The chat server then uses the applicant identifier to
access information about the application in the application
database. It should be noted that the applicant identifier may be
used as an application identifier in circumstances such as would be
expected for an online credit card application where there is one
and only one application per applicant. In other embodiments, an
application identifier that is unique for each application is
assigned and used. In this description, wherever an applicant
identifier is mentioned, an application identifier could also be
used.
[0128] Sending the applicant identifier to the chat server instead
of sending the current web page or other information to the chat
server is preferable from a security standpoint because the
applicant identifier can only be used to obtain information about
the application by accessing application database 1103. In
addition, preferably, the applicant identifier is encrypted, adding
a further level of security.
[0129] In the embodiment shown, chat server 1108 does not have a
direct link to the application database 1103. Chat server 1108 is
connected to a customer service agent 1110. Customer service agent
1110 handles the chat session, responding to requests made by the
applicant. Other customer service agents 1112 and 1114 are also
standing by to handle other chat sessions generated by chat server
1108. In one embodiment, requests made to the chat server are
queued and the next available customer service agent is assigned to
the first chat session request found in the queue.
[0130] Customer service agent 1110 is connected to a counter offer
server that is connected to application database 1103. By passing
the applicant identifier from the chat server to the customer
service agent to the application database through the counter offer
server, information about the applicant can be obtained from the
application database. Connections from the customer service agent
to the counter offer server and from the counter offer server to
the application database may be made over the Internet or may be a
dedicated secure connection.
[0131] In the embodiment shown, which is adapted specifically for
implementing a counter offer strategy as is described below, a
separate web server 1102 and counter offer server 1120 are shown.
This divides the processing demand generated by normal
communication with a browser from the processing demand generated
by interaction initiated by chat with a customer service agent.
This architecture is particularly useful since the two types of
traffic are isolated. In other embodiments, the functions of the
web server and the counter offer server are performed by a single
application server. Dashed box 1122 represents a single application
server that may include both the web server and the counter offer
server. In general, the term application server is used to describe
either the web server and counter offer server operating
collectively or to describe a single server performing both the
function of the web server and the counter offer server.
[0132] Additionally, in a system where a counter offer is not
generated, counter offer server 1120 may be referred to as a
customer service agent server or some other term describing its
primary function. The important point is that both the web server
and the counter offer server both access the application data base
to obtain information about the status of the application. In
addition, both the web server and the counter offer server may
write data to the application database in some embodiments. The
common access to the application database enables the customer
service agent to obtain information about the status of the
application using the applicant identifier received through the
chat server and also allows the customer service agent to alter the
status of the application based on information received from the
applicant through the chat server by sending that information to
the counter offer server for posting to the application
database.
[0133] Thus, an applicant provides information to database 1103 via
the Internet using web pages in a standard manner. In addition, the
applicant may communicate via chat with a customer service agent
who also is connected to the application database and may change
the state of the application according to information received by
the applicant via chat. In the embodiment shown, the customer
service agent interacts with a special purpose counter offer server
that uses the information provided by the applicant to determine a
counter offer using information in the application database. The
counter offer is stored in the application database and provided to
the applicant's browser via the web server. As noted above, the
counter offer server and the web server may be implemented on a
single machine referred to as the application server. The various
processes operating on the application server, the chat server and
the browser are described below for the purpose of illustrating how
the chat window may be activated and a counter offer generated for
the applicant.
[0134] FIG. 16 is a flowchart illustrating a general process
implemented on the chat server. The process starts at 1200. In a
step 1202, the applicant identifier is obtained from a browser. In
a step 1204, the chat server validates the applicant information by
communicating with the application database. In some embodiments,
the chat server may communicate directly with the application
database. In other embodiments, as shown in FIG. 15, the chat
server communicates with the application database through an
application server. After the applicant information is validated, a
response is received from the applicant via chat. Based on the
response, the applicant account is configured in a step 1208 and
the process ends at 1210.
[0135] FIG. 17 is a flow chart illustrating a general process
implemented on the web server for sending dynamic web pages to the
applicant. The dynamic web pages differ from a standard web page
used to interact with the applicant because they contain a page
object used to initiate a chat section with a chat server upon the
occurrence of certain events. The page object includes an applicant
identifier that is passed to the chat server. The process starts at
1300 when chat is initiated based on a user action. As described
above, the user action may be the activation of a help or chat
button or the user canceling out of the application. Chat may also
be activated by user inaction when a response is not received or by
an improper action taken by a user resulting in an invalid
response. In a step 1302, the state of the application is
determined. Next, in a step 1304, the content of the page to be
sent to applicant is determined based on the state of the
application. Next, in a step 1306, the applicant identifier is
inserted into a page object. In a step 1308, the page is sent to
the applicant browser and the process ends at 1310.
[0136] FIG. 18 is a flow chart illustrating a process implemented
on a browser for establishing a connection to a chat server. The
process starts at 1400. In a step 1402, a link to the chat server
is activated either directly by the user or as a result of the
occurrence of an event as described above. In a step 1404, a
connection is established to the chat server. Typically the
connection uses a protocol such as HTTPS. Next, in a step 1406, the
applicant identification is sent to the chat server and the process
ends at 1408.
[0137] FIG. 19 is a flowchart illustrating a typical process
implemented on the browser for the purpose of initializing chat
when the user does not respond to a downloaded web page in a
certain period of time. The process starts at 1500. In a step 1502,
a timer is initialized. Control is then transferred to 1504 where
periodic checks are made to determine whether the timer has
expired. If a valid user input is received, control is transferred
to a step 1506 and the timer is reset. If the timer expires, then
control is transferred to a step 1508 and a chat session is
initiated as described above. The process then ends at 1510.
[0138] FIG. 20 is a flow chart illustrating a process implemented
on a chat server when a chat session is requested by a browser as
described above. The process starts at 1600 when the request is
received. The request for a chat session includes both a connection
request and the applicant identifier. In a step 1602, the request
is put into a queue and the applicant identifier is stored in a
manner that associates it with the request. In some embodiments,
the chat server uses the applicant identifier while the request is
still in the queue to obtain the application information from the
application database. In other embodiments, the applicant
identifier is not used to access the application database until the
request is assigned to a customer service agent. This insures that
when the customer service agent accesses the information about the
application, the information is up to date. In a step 1604, a
status message is sent to the user and the system then waits for an
available customer service agent. So long as no customer service
agent is available, the system continues to wait at 1604. When a
customer service agent becomes available, control is transferred to
a step 1606 and the application information is sent to the customer
service agent. The customer service agent then uses the application
information to discuss the state of the application with the
applicant.
[0139] FIG. 21A is a flow chart illustrating a process implemented
at a customer service agent for the purpose of supporting the chat
session. The process may be implemented on a client machine
accessed by the customer service agent or may be implemented on the
application server which may include a dedicated counter-offer
server. The process starts at 1700. In a step 1702, the customer
service agent notifies the chat server that it is available. Next,
in a step 1704, the applicant identifier is received from the chat
server. In a step 1706, the applicant record in the application
database is accessed using the applicant identifier as mentioned
above. The application record may be accessed either directly or
via the application server. In a step 1708, the chat server
displays the application data retrieved using the applicant
identifier to the customer service agent. In one embodiment, the
application data is displayed by displaying the same web page that
the applicant is viewing. In addition, the web page may be
augmented with other information about the status of the
application. Alternatively, a completely separate application
information screen may be displayed to the customer service
agent.
[0140] In an embodiment where a counter offer is generated by the
customer service agent, a display is provided showing various offer
terms that the applicant may indicate are not acceptable in the
chat between the applicant and the customer service agent. The
customer service agent may check one or more of the terms and the
terms checked by the customer service agent are sent to the counter
offer server to be used in generating a counter offer. The terms or
attributes of the offer that the applicant considers to be
unacceptable are obtained in a step 1712 and the initial process
for receiving applicant information and providing information to
the counter offer server ends at 1714.
[0141] It should be noted that a number of different methods of
obtaining the unacceptable terms from the applicant may be used. In
one embodiment, as described above, a set of offer terms are shown
to the customers service agent and the customer service agent
selects terms identified by the applicant in chat that are
unacceptable. In other embodiments, a display of terms is provided
to the applicant and the applicant picks the unacceptable terms
with the aid of the customer service agent. In yet another
embodiment, the chat generated by the applicant is automatically
analyzed by a program which generates the list of unacceptable
terms for the counter offer server.
[0142] FIG. 21B is a screen shot illustrating a display of offer
terms used in one embodiment for determining which terms are
unacceptable. The display includes indications that interest rate
attributes are not acceptable, indicating that the annual
percentage rate or long term interest rate is too high, a longer
introductory interest rate is desired, or an introductory interest
rate is desired. The introductory interest rate is a very low rate
offered for a short period of time when the account is established,
also referred to as a teaser rate. In addition, buttons are
provided for the customer service agent to check whether the credit
limit is too low either for purchases or for balance transfers. In
addition, the customer service agent can fill in a balance transfer
amount that the applicant wants to transfer as well as a requested
credit limit. Finally, a box is provided for the customer service
agent to check and send the data to the counter offer server.
[0143] FIG. 22 is a flow chart illustrating in detail a process
implemented in step 1712 for obtaining the unacceptable terms of an
offer from an applicant. The process starts at step 1800. In a step
1802, a chat message is received from a user indicating a term that
the user would like to change. The message is displayed to the
customer service agent along with a checklist as shown in FIG. 21B
illustrating terms to change. As noted above, the checklist may
also be displayed and checked by the applicant. In a step 1806, an
input is received from the customer service agent of a selected
term that the applicant would like to change of an offer. In a step
1808, the term is sent to the counter offer server and the process
ends at 1810.
[0144] FIG. 23 is a flow chart illustrating the process implemented
on the counter offer server when more than one term is selected as
being unacceptable to the applicant. In one embodiment, a counter
offer is selected based on only one unacceptable term being
changed. This simplifies the process of determining a counter offer
since changing two terms is somewhat more complex. Therefore, a
hierarchy of terms that may be changed by the applicant is provided
and the highest priority term selected is used to determine the
counter offer. All of the unacceptable terms are still transmitted
to the counter offer server and recorded for the purpose of data
gathering and analysis of the system. The process starts at 1900.
In a step 1902, multiple unacceptable terms or attributes of the
offer are received by the counter offer server. Next, in a step
1904, the highest priority term or attribute that is unacceptable
is determined. Next, in a step 1906, the offer is adjusted and a
counter offer is determined based on the highest priority term. The
process ends at 1908.
[0145] Many different methods may be used by the counter offer
server to generate a counter offer based on attributes or terms
identified by the applicant as being unacceptable. In one
embodiment, a number of potential offers are identified based on
the applicant information provided and an assessment of the risk
associated with extending credit to the applicant. Some of the
generated offers are withheld while others are displayed to the
applicant. A number of schemes may be used to decide which offers
are displayed and which offers are withheld. Some methods may
include a statistical selection or a selection according to a
marketing scheme designed to increase the rate of acceptance. It
may also be the case that the best offer is withheld and kept in
reserve to use as a counter offer. In general, certain potential
offers are withheld.
[0146] The identification by the applicant of an unacceptable term
is used by the counter offer server to identify a better offer for
the counter offer. In one embodiment, offer strategies are
identified and the counter offer is identified by simply looking up
an offer strategy associated with the applicant and the identified
unacceptable term. In one embodiment, an offer strategy may include
a set of offers shown to the applicant as well as offers that are
not displayed and that correspond to various unacceptable terms.
When an unacceptable term is identified, the offer corresponding to
the strategy and the unacceptable term is used as the counter
offer.
[0147] In some embodiments, the counter offer strategy is dependent
on characteristics of the applicant. For example, the applicant may
be classified as a "surfer" or "non-surfer". A "surfer" is a person
who shifts or surfs balances among credit cards, taking advantage
of low teaser rates. A determination that an applicant is a surfer
is made based on an analysis of the applicant's credit report. A
counter offer strategy designed for such an applicant may adopt the
strategy of extending the period of an introductory rate if
requested by the applicant, but requiring the applicant to make a
certain number of purchases or not transfer the balance for a
certain period of time.
[0148] In general, added terms and conditions such as purchase
requirements or a length of time that a balance may not be
transferred from the card may be added to counter offers for the
purpose of creating a perceived barrier to receive the counter
offer. Such a barrier or condition prevents the applicant from
deciding that the first offer should always be rejected. In some
embodiments, the conditions are determined based on characteristics
of the applicant. As described above, surfers may receive balance
transfer time restrictions.
[0149] In addition to selecting a withheld offer based on a
pre-determined offer scheme, the counter offer server may also
recalculate a customized offer based on the identification of an
unacceptable term and an actual requested term by the applicant.
For example, the applicant may express that the credit limit is too
low, either for a desired balance transfer that the applicant wants
to make or new purchases. The amount of the credit limit minus the
amount of the balance transfer is referred to as the amount of
credit that is "open to buy". The information sent to the counter
offer server may include a requested credit limit and a requested
balance transfer amount. From that information, the counter offer
server can determine that the offer credit limit is too low either
for the balance transfer requested or for the amount that the
applicant wants open to buy. To minimize risk, it is desirable that
the credit limit be as low as possible. Therefore, it is desirable
not to simply select a withheld offer with a higher credit limit,
but instead to customize an offer that conforms to the applicant's
request but does not exceed the applicant's request.
[0150] Accordingly, a new credit limit may be calculated that
incorporates the requested balance transfer and the amount that the
applicant wants open to buy. The calculated new offer is of course
checked versus the risk profile of the user and it is verified that
the higher credit limit is appropriate for the user. Any of the
various techniques well known in the art of assigning credit may be
used to assess the risk of the applicant and determine an
appropriate upper credit limit. Significantly, the counteroffer in
the case of a requested higher credit limit is specifically
customized for the applicant based on what the applicant requests.
In general, any counter offer provided is based on the applicant's
identification of an unacceptable term. In some embodiments, if no
counter offer is available that improves an unacceptable term
identified by the applicant, then a message is returned to the
applicant either directly or through the chat interface that
indicates that no counter offer can be provided at that time. For
example, in one embodiment, the offer strategy may include an offer
with the best annual percentage rate available in the set of offers
initially displayed to the applicant. In such a case, if the
applicant identifies the annual percentage rate as the unacceptable
term, then no counter offer improving that term can be
generated.
[0151] FIG. 24 is a flow chart illustrating an example process for
generating a counter offer. The process starts at 11000. In a step
11010, the counter offer server receives the term that is to be
changed. Next, in a step 11020, it is determined whether the term
is the credit limit or not. If the term is not the credit limit,
then control is transferred to a step 11030 and a precomputed offer
that was withheld is determined for display. The counter offer
determination process then ends at 11040. If the term is the credit
limit, then control is transferred to a step 11050 and it is
determined whether the credit limit is too low for a requested
balance transfer or for new purchases (open to buy). If the credit
limit is too low for new purchases, then control is transferred to
a step 11060 and the required balance transfer and credit limit are
adjusted if that is allowed by the scheme being used to assign
credit based on an assessment of the applicant's risk.
[0152] If the credit limit is too low for a requested balance
transfer, then control is transferred to a step 11070 and the
credit limit is adjusted based on the balance transfer requested if
allowed by the credit line assignment being used. After the credit
limit is adjusted in steps 11060 or 11070, the counter offer is
defined and the counter offer determination process ends at 11080.
Whether a precomputed offer is determined for display in 11030 or
the credit limit is recomputed in step 11060 or 11070, if no better
offer can be generated, then a message noting that no better offer
can be generated is sent either to the chat server or to the
applicant directly.
[0153] Once a counter offer has been defined or it has been
determined that no counter offer that improves the unacceptable
terms can be generated, the applicant is notified of the counter
offer terms. In different embodiments, notification may be
accomplished in various ways. For example, in one embodiment, a new
offer page is generated in the application server based on data
written to the application database by the application server. In
the embodiment where the application server is split into a web
server and a counter offer server, the counter offer server writes
data to the application database and the web server generates a
counter offer page based on the data written to the application
database. In addition, the application server also provides
information to the chat server indicating what counter offer, if
any, has been generated. The customer service agent then discusses
the counter offer with the applicant via the chat interface. In
order to view the counter offer page generated by the web server,
the applicant is asked to refresh his browser. Refreshing the
browser causes the offer page to be requested from the web server
and the web server responds with the counter offer page. In one
embodiment, a button labeled "view offer" is provided on the
displayed page. When the button is selected, the page is downloaded
again and any changes are then viewed by the user.
[0154] In other embodiments, the displaying of the counter offer
page to the applicant is handled somewhat differently. In one
embodiment, the chat server enables the display of the page through
the applicant's browser automatically, without requiring the
applicant to refresh the screen. This can be accomplished in a
variety of ways. In one embodiment, the chat server writes a
variable to a memory location that the browser checks periodically.
When the browser checks the location and finds a variable
indicating that the counter offer page should be downloaded, the
browser automatically refreshes itself. The applet that enables the
browser to check the location and refresh itself may be used in
some cases but not others. When such an applet is not used, the
process of instructing the applicant through the chat interface to
refresh his own browser or to select a button to view the offer may
be implemented.
[0155] FIG. 25 is a flowchart illustrating a process implemented on
a counter offer server to generate and confirm a new offer for
display to the applicant. The process starts at 11100. In a step
11110, the counter offer server receives a chat generated term to
change. As described above, the term can be identified based on
chat by a customer service agent or the term can be automatically
determined by analysis of the chat provided by the applicant or the
term can be identified using a pick list provided to the applicant.
In a step 11120, a new offer is selected from an offer set included
in the offer strategy being used for the applicant. As described
above, in some embodiments, a new offer is actually calculated
based on information provided by the applicant such as a requested
credit limit. Next, in a step 11130, the new offer is displayed to
the customer service agent. The customer service agent then
communicates with the applicant about the new offer to determine
the applicant's interest. The customer service agent then confirms
to the counter offer server that the new offer is to be shown to
the applicant. The confirmation is received in step 11140 and in a
step 11150, the counter offer server confirms the new offer in the
data base so that it is ready to be displayed when the applicant's
browser refreshes. The process then ends at 11160.
[0156] In some embodiments, the new offer is confirmed in the
database concurrent with it being displayed to the customer service
agent. Then, whenever the applicant's browser refreshes, the
counter offer will be displayed. In some embodiments, it is desired
that the display of the counter offer not be enabled until customer
service agent has an opportunity to chat with the applicant about
the new offer and confirm that display is appropriate.
[0157] FIG. 26 is a flowchart illustrating a process implemented on
the web server portion of the application server for the purpose of
displaying a new counter offer to the applicant. The process starts
at 11200. In a step 11210, the web server receives a refresh
request from the applicant's browser. Next, in a step 11220, the
counter offer parameters are retrieved from the application data
base and a web page including the counter offer is generated. Then
in a step 11230, the counter offer page is sent to the browser. The
process ends at 11240.
[0158] FIG. 27 is a flow chart illustrating a process used in one
embodiment to automatically generate a refresh on the applicant's
browser. The process starts at 11300. In a step 11310, a request is
received for a different offer from the customer service agent. The
new offer is determined in a step 11320. The terms of the new offer
are communicated to the customer service agent in step 11330. In a
step 11340, the customer service agent describes the offer to the
user. Then, in a step 11350, the customer service agent receives an
indication that the user wants to view the new offer. The customer
service agent then sends a message to the user in step 11360 that
causes a refresh to be activated. As described above, the message
may include writing a certain value to a defined memory location
that is periodically examined by the browser for the purpose of
determining whether a refresh has been requested by the customer
service agent. Once one refresh is generated in this manner, the
value that the browser looks for may be incremented so that each
time it finds the same value, a new refresh is not generated. The
process ends at 11370.
[0159] A system and method for activating a chat interface with a
customer service agent that has access to information about an
application for credit has been described. In one embodiment, the
chat interface is used to obtain information about why an applicant
is rejecting an offer of credit and to identify unacceptable terms.
Those unacceptable terms are communicated to a counter offer server
and the counter offer server generates a new offer that improves
the unacceptable term. The new offer is communicated to the
applicant using the chat interface and a web page showing the new
offer with an opportunity to accept the offer is displayed to the
applicant when the applicant's browser is refreshed.
[0160] Although the foregoing invention has been described in some
detail for purposes of clarity of understanding, it will be
apparent that certain changes and modifications may be practiced
within the scope of the appended claims. It should be noted that
there are many alternative ways of implementing both the process
and apparatus of the present invention. Accordingly, the present
embodiments are to be considered as illustrative and not
restrictive, and the invention is not to be limited to the details
given herein, but may be modified within the scope and equivalents
of the appended claims.
* * * * *