U.S. patent application number 12/125820 was filed with the patent office on 2008-11-27 for system and method for automated detection of never-pay data sets.
Invention is credited to Christopher J. Celka, Cristian R. Rojas.
Application Number | 20080294540 12/125820 |
Document ID | / |
Family ID | 40073287 |
Filed Date | 2008-11-27 |
United States Patent
Application |
20080294540 |
Kind Code |
A1 |
Celka; Christopher J. ; et
al. |
November 27, 2008 |
SYSTEM AND METHOD FOR AUTOMATED DETECTION OF NEVER-PAY DATA
SETS
Abstract
Data filters, models, and/or profiles for identifying and/or
predicting the never-pay population (for example, those customers
that make a request for credit and obtain the credit instrument but
over the life of the account, never make a payment) can be useful
to various commercial entities, such as those issuing mortgages,
home equity lines of credit, consumer or business lines of credit,
automobile loans, credit card accounts, or those entities providing
services, such as utility services, phone services, and the
like.
Inventors: |
Celka; Christopher J.;
(Suwanee, GA) ; Rojas; Cristian R.; (San Diego,
CA) |
Correspondence
Address: |
KNOBBE MARTENS OLSON & BEAR LLP
2040 MAIN STREET, FOURTEENTH FLOOR
IRVINE
CA
92614
US
|
Family ID: |
40073287 |
Appl. No.: |
12/125820 |
Filed: |
May 22, 2008 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60931902 |
May 25, 2007 |
|
|
|
Current U.S.
Class: |
705/35 |
Current CPC
Class: |
G06Q 40/00 20130101;
G06Q 20/10 20130101; G06Q 30/06 20130101; G06Q 40/025 20130101 |
Class at
Publication: |
705/35 |
International
Class: |
G06Q 40/00 20060101
G06Q040/00 |
Claims
1. A never-pay automated detection system, the system comprising: a
processor configure to run software modules; a data storage device
storing a plurality of consumer records comprising credit bureau
data, tradeline data, historical balance data, and demographic
data, the data storage device in electronic communication with the
computer system; and a never-pay module configured to: identify a
subset of the plurality of consumer records from the data storage
device; receive a first never-pay data profile from a storage
repository, the first never-pay data profile identifying consumer
records that are likely or substantially likely to never make a
payment; apply the first never-pay data profile to each of the
subset of the plurality of consumer records to generate a first
never-pay score for each of the subset of the plurality of consumer
records; and store in a database an aggregate never-pay score
associated with the subset of the plurality of the consumer
records, the aggregate never-pay score comprising at least the
first never-pay score; the processor able to run the never-pay
module.
2. The never-pay automated detection system of claim 1, the
never-pay module further configured to receive a second never-pay
data profile from the storage repository, the second never-pay
profile identifying consumer records that are likely or
substantially likely to never make a payment, and apply the second
never-pay profile to each of the subset of plurality of consumer
records to generate a second never-pay score for each of the subset
of plurality of consumer records to be included in the aggregate
never-pay score.
3. The never-pay automated detection system of claim 2 the
never-pay module further configured to receive a third never-pay
data filter from the storage repository, the third never-pay
profile identifying consumer records that are likely or
substantially likely to never make a payment, and apply the third
never-pay filter to each of the subset of plurality of consumer
records to generate a third never pay score for each of the subset
of plurality of consumer records to be included in the aggregate
never-pay score.
4. The never-pay automated detection system of claim 1, the
never-pay module further configured to electronically select the
first never-pay data profile from a plurality of never-pay data
profiles, the criteria being based at least in part on a customer
selection based on price.
5. The never-pay automated detection system of claim 1, the
never-pay module further configured to electronically select the
first never-pay data profile from a plurality of never-pay data
profiles, the criteria being based at least in part on a customer
selection based on response speed.
6. A computer implemented method for maintaining a database
comprising: electronically identifying a plurality of consumer
records, wherein the consumer records comprise credit bureau data,
tradeline data, historical balance data, and demographic data;
electronically receiving a first never-pay data filter from a
storage repository; electronically applying the first never-pay
data filter to each of the plurality consumer records to generate a
first never pay score for each of the plurality of consumer
records; and electronically storing in a database an aggregate
never-pay score associated with each of the consumer records, the
aggregate never-pay score comprising at least the first never-pay
score.
7. The computer implemented method of claim 6 further comprising
electronically receiving a second never-pay data filter from the
storage repository and electronically applying the second never-pay
filter to each of the plurality of consumer records to generate a
second never-pay score for each of the plurality of consumer
records to be included in the aggregate never-pay score.
8. The computer implemented method of claim 7 further comprising
electronically receiving a third never-pay data filter from the
storage repository and electronically applying the third never-pay
filter to each of the plurality of consumer records to generate a
third never pay score for each of the plurality of consumer records
to be included in the aggregate never-pay score.
9. The never-pay automated detection system of claim 6, further
comprising a criteria for electronically retrieving the first
never-pay data filter from a plurality of never-pay data filters,
the criteria based at least in part on a selection by a customer
based on price.
10. The never-pay automated detection system of claim 6, further
comprising a criteria for electronically retrieving the first
never-pay data filter from a plurality of never-pay data filters,
the criteria being based at least in part on a selection by a
customer based on response speed.
11. A storage medium having a computer program stored thereon for
causing a suitably programmed system to process computer-program
code by performing the method of claim 6 when such program is
executed on the system.
12. A never-pay automated detection system, the system comprising:
a processor configured to run software modules; a data storage
device storing a plurality of credit data records, the data storage
device in communication with the processor; and a never-pay module
configured to: identify records in the data storage device that are
defined as never-pay records which are likely to indicate consumers
that are likely or substantially likely never to make a payment;
track the identified records over a time period; and develop a
first never-pay data profile that predicts the propensity of a
consumer to be a never-pay record using the tracked identified
records, the processor able to run the never-pay module.
13. The never-pay automated detection system of claim 12, the
never-pay module further configured to store the data profile in a
data repository.
14. The never-pay automated detection system of claim 12, the data
profile comprising a first party fraud attribute.
15. The never-pay automated detection system of claim 12, the data
profile comprising a third party fraud attribute.
16. A computer implemented method of developing a data filter for
automatically identifying never-pay database records comprising:
electronically identifying records of a database that are defined
as never-pay records which are likely to indicate consumers that
are likely or substantially likely never to make a payment;
electronically tracking the identified records over a time period;
and electronically developing a data filter that predicts the
propensity of a consumer to be a never-pay record using the
electronically tracked identified records.
17. The computer implemented method of claim 16 further comprising
electronically storing the data filter in a data repository.
18. A storage medium having a computer program stored thereon for
causing a suitably programmed system to process computer-program
code by performing the method of claim 16 when such program is
executed on the system.
19. The computer implemented method of claim 16, further comprising
electronically applying the data filter to a selected consumer
record to generate a never-pay score for the selected consumer
record, the never-pay score being predictive of the consumer to be
a never-pay record.
20. The computer implemented method of claim 19, further comprising
electronically sending marketing material to a consumer linked to
the never-pay score if the never-pay score is below a certain
threshold.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims the benefit of U.S. Provisional
Application No. 60/931,902, titled METHODS AND SYSTEMS FOR MODELING
NEVER-PAY POPULATION and filed on May 25, 2007, which is hereby
incorporated by reference in its entirety, specifically the systems
and methods for modeling the never-pay population as disclosed
therein.
BACKGROUND
[0002] 1. Field of the Invention
[0003] This disclosure generally relates to data filters for
modeling and processing credit report data and other data, and more
particularly to improved systems and methods for generating and
using data filters configured to conduct customer profiling and
customer analysis relating to modeling, identifying, and/or
predicting the never-pay population.
[0004] 2. Description of the Related Art
[0005] Various financial service entities provide credit accounts,
such as, for example, mortgages, automobile loans, credit card
accounts, and the like, to consumers and or businesses. Prior to
providing a credit account to an applicant, or during the servicing
of such a credit account, many financial service providers want to
know whether the applicant or customer will be or is likely to be
within the "never-pay" population. The never-pay population
includes without limitation those customers that make a request for
credit, subsequently obtain the credit instrument, and over the
life of the account, never make a payment or substantially never
make a payment. Although the never-pay population is not always
large (however, it can be a large population for certain financial
firms, for example, those firms serving the sub-prime market or the
like), it is a costly population to financial service providers and
other entities. Most financial service providers can attribute a
certain percentage of their losses to the never-pay population.
[0006] Traditional scoring models do not provide the necessary
insight to identify the never-pay population. In part, this is due
to the diversity of profiles that underlie these populations.
Additionally, the attributes and/or reasons that contribute to the
never-pay population are difficult to identify for some financial
service providers because of their limited resources and the
complexity of analyzing the never-pay population. Accordingly,
these never-pay accounts are not identified early in the process,
and are treated as typical credit loss and are often written off as
bad debt.
SUMMARY
[0007] Never-pay data filters, models, and/or profiles can be
generated and applied to both data for potential and actual
customers (for example, individual consumers, businesses, or the
like) to determine their propensity to never make a payment on a
credit account.
[0008] In an embodiment, a never-pay automated detection system,
the system comprising: a processor configure to run software
modules; a data storage device storing a plurality of consumer
records comprising credit bureau data, tradeline data, historical
balance data, and demographic data, the data storage device in
electronic communication with the computer system; and a never-pay
module configured to: identify a subset of the plurality of
consumer records from the data storage device; receive a first
never-pay data profile from a storage repository, the first
never-pay data profile identifying consumer records that are likely
or substantially likely to never make a payment; apply the first
never-pay data profile to each of the subset of the plurality of
consumer records to generate a first never-pay score for each of
the subset of the plurality of consumer records; and store in a
database an aggregate never-pay score associated with the subset of
the plurality of the consumer records, the aggregate never-pay
score comprising at least the first never-pay score; the processor
able to run the never-pay module.
[0009] In another embodiment, the never-pay module further
configured to receive a second never-pay data profile from the
storage repository, the second never-pay profile identifying
consumer records that are likely or substantially likely to never
make a payment, and apply the second never-pay profile to each of
the subset of plurality of consumer records to generate a second
never-pay score for each of the subset of plurality of consumer
records to be included in the aggregate never-pay score. In an
embodiment, the never-pay module further configured to receive a
third never-pay data filter from the storage repository, the third
never-pay profile identifying consumer records that are likely or
substantially likely to never make a payment, and apply the third
never-pay filter to each of the subset of plurality of consumer
records to generate a third never pay score for each of the subset
of plurality of consumer records to be included in the aggregate
never-pay score.
[0010] In an embodiment, a computer implemented method for
maintaining a database comprising: electronically identifying a
plurality of consumer records, wherein the consumer records
comprise credit bureau data, tradeline data, historical balance
data, and demographic data; electronically receiving a first
never-pay data filter from a storage repository; electronically
applying the first never-pay data filter to each of the plurality
consumer records to generate a first never pay score for each of
the plurality of consumer records; and electronically storing in a
database an aggregate never-pay score associated with each of the
consumer records, the aggregate never-pay score comprising at least
the first never-pay score.
[0011] In an embodiment, the computer implemented method further
comprising electronically receiving a second never-pay data filter
from the storage repository and electronically applying the second
never-pay filter to each of the plurality of consumer records to
generate a second never-pay score for each of the plurality of
consumer records to be included in the aggregate never-pay score.
In an embodiment, the computer implemented method further
comprising electronically receiving a third never-pay data filter
from the storage repository and electronically applying the third
never-pay filter to each of the plurality of consumer records to
generate a third never pay score for each of the plurality of
consumer records to be included in the aggregate never-pay
score.
[0012] In an embodiment, the never-pay automated detection system
comprises a processor configured to run software modules; a data
storage device storing a plurality of credit data records, the data
storage device in communication with the processor; and a never-pay
module configured to: identify records in the data storage device
that are defined as never-pay records which are likely to indicate
consumers that are likely or substantially likely never to make a
payment; track the identified records over a time period; and
develop a first never-pay data profile that predicts the propensity
of a consumer to be a never-pay record using the tracked identified
records, the processor able to run the never-pay module.
[0013] In an embodiment, a computer implemented method of
developing a data filter for automatically identifying never-pay
database records comprising: electronically identifying records of
a database that are defined as never-pay records which are likely
to indicate consumers that are likely or substantially likely never
to make a payment; electronically tracking the identified records
over a time period; and electronically developing a data filter
that predicts the propensity of a consumer to be a never-pay record
using the electronically tracked identified records.
[0014] For purposes of this summary, certain aspects, advantages,
and novel features of the invention are described herein. It is to
be understood that not necessarily all such aspects, advantages,
and features may be employed and/or achieved in accordance with any
particular embodiment of the invention. Thus, for example, those
skilled in the art will recognize that the invention may be
embodied or carried out in a manner that achieves one advantage or
group of advantages as taught herein without necessarily achieving
other advantages as may be taught or suggested herein.
BRIEF DESCRIPTION OF THE DRAWINGS
[0015] The foregoing and other features, aspects and advantages of
the present invention are described in detail below with reference
to the drawings of various embodiments, which are intended to
illustrate and not to limit the invention. The drawings comprise
the following figures in which:
[0016] FIG. 1 is a block diagram illustrating an embodiment of a
computer hardware system configured to run software for
implementing one or more embodiments of the never-pay data filter
system described herein.
[0017] FIG. 2 is a block diagram depicting an embodiment of a
credit database that comprises data obtained from various data
sources.
[0018] FIG. 3 is a flowchart diagram illustrating an embodiment for
analyzing data to create never-pay data filters, models and/or
profiles.
[0019] FIG. 4 is a flowchart diagram illustrating an embodiment for
analyzing data to apply never-pay data filters, models, and/or
profiles to assess the propensity of a customer to become a
never-pay record.
[0020] FIG. 5 is flowchart diagram illustrating an embodiment
wherein multiple data filters, models, and/or profiles are applied
to the credit data of an individual(s)/customers(s) to determine an
aggregate never-pay score.
[0021] FIG. 5A is flowchart diagram illustrating an embodiment
wherein multiple data filters, models, and/or profiles are applied
to the credit data of a particular individual to determine an
aggregate never-pay score.
[0022] FIG. 6 is flowchart diagram illustrating an embodiment
wherein other data filters, models, and/or profiles are applied to
the credit data of an individual(s)/customers(s) to determine an
aggregate never-pay score.
[0023] FIG. 7 is flowchart diagram illustrating an embodiment for
applying the aggregate never-pay score to determine whether to
perform a business action or the like.
DESCRIPTION OF THE EMBODIMENTS
[0024] Embodiments of the invention will now be described with
reference to the accompanying figures, wherein like numerals refer
to like elements throughout. The terminology used in the
description presented herein is not intended to be interpreted in
any limited or restrictive manner, simply because it is being
utilized in conjunction with a detailed description of certain
specific embodiments of the invention. Furthermore, embodiments of
the invention may comprise several novel features, no single one of
which is solely responsible for its desirable attributes or which
is essential to practicing the inventions herein described.
[0025] As used herein the terms "individual(s)," "customer(s),"
"consumer(s)", "applicant(s)", or "business(es)", as used herein,
are broad terms and are to be interpreted to include without
limitation applicants, consumers, customers, single individuals as
well as groups of individuals (for example, married couples or
domestic partners or the like), business entities, organizations,
or the like.
[0026] In general, the term "module," as used herein, refers to
logic embodied in hardware or firmware, or to a collection of
software instructions, possibly having entry and exit points,
written in a programming language, such as, for example, Java, Lua,
C or C++. A software module may be compiled and linked into an
executable program, installed in a dynamic link library, or may be
written in an interpreted programming language such as, for
example, BASIC, Perl, or Python. It will be appreciated that
software modules may be callable from other modules or from
themselves, and/or may be invoked in response to detected events or
interrupts. Software instructions may be embedded in firmware, such
as, for example, an EPROM. It will be further appreciated that
hardware modules may be comprised of connected logic units, such
as, for example, gates and flip-flops, and/or may be comprised of
programmable units, such as, for example, programmable gate arrays
or processors. The modules described herein are preferably
implemented as software modules, but may be represented in hardware
or firmware. Generally, the modules described herein refer to
logical modules that may be combined with other modules or divided
into sub-modules despite their physical organization or
storage.
[0027] In general, the terms "data filter," "model," and "profile"
as used herein are broad terms that are interchangeable, and
generally refer without limitation to systems, devices, and methods
for amplifying, selecting, filtering, excluding, predicting, and/or
identifying subsets of a dataset that are relevant, substantially
relevant, and/or statistically relevant to the user.
[0028] As used herein, the terms "financial entity," "credit
providers," "credit issuers," "financial institutions," "clients,"
"utility providers," "utility service providers," "phone service
providers," "financial service providers," are broad
interchangeable terms and generally refer without limitation to
banks, financial companies, credit unions, savings institutions,
retailers, utility (telecommunications, gas, electric, water,
sewer, or the like) providers, bankcard issuers, credit card
issuers, mortgage (for example, sub-prime) lenders, and the
like.
[0029] Generally, the terms "never-pay" and "straight roller" as
used herein are broad terms that are interchangeable, and generally
refer without limitation to those customers that make a request for
credit, subsequently obtain the credit instrument, and over the
life of the account, never make a payment or substantially never
make a payment. In an embodiment, the terms "substantially never
make a payment" or "substantially likely never to make a payment"
are based on various factors including without limitation type of
credit/loan, number of credit/loan payments, duration of
credit/loan period, amount of credit/loan, size of payment of
credit/loan, or the like. Additionally, the foregoing broad terms
can also refer without limitation to a booked account that rolls
straight to loss without the lender, credit issuer, or the like
collecting any fund from the consumer.
[0030] Data filters, models, and/or profiles for identifying and/or
predicting the never-pay population (for example, those customers
that make a request for credit and obtain the credit instrument but
over the life of the account, never make a payment) can be useful
to various commercial entities, such as those issuing mortgages,
home equity lines of credit, consumer or business lines of credit,
automobile loans, credit card accounts, or those entities providing
services, such as utility services, phone services, and the
like.
[0031] Some acquisition risk data filters/models and fraud data
filters/models identify the respective subsets of the never pay
population that align with acquisition risk or fraud data
filters/models that they are configured to predict. Such risk
models tend to focus on the macro level of risk (for example, 90+
days past due and bankruptcy), while such fraud models attempt to
identify some form of fraud, typically identity fraud. The never
pay population is, however, comprised of multiple models and/or
profiles, some of which do not entirely resemble those of
acquisition risk and/or fraud data filters/models of credit risk
consumers. Accordingly, in an embodiment, the never-pay data
filters and/or profiles include without limitation, the following,
and those skilled in the art will recognize other possible data
filters, models, and/or profiles without limiting the scope of the
disclosure herein.
[0032] a) Credit risk data filter and/or profile/model--consumers
whose credit profiles include multiple delinquent or derogatory
tradelines. These consumers tend to score poorly on risk models,
such as, for example, VantageScore.sup.SM or other scores such as,
generic risk scores.
[0033] b) No intent to pay data filter and/or profile/model--a
behavioral pattern in which a consumer seeks and obtains credit
with no intention of ever paying the debt obligation.
[0034] c) Synthetic credit data filter and/or profile/model--the
combining of real and fictitious identification data in order to
establish a consumer credit profile. These profiles may not
resemble those of a risky consumer. Therefore, risk scores tend to
have difficulty identifying these profiles.
[0035] d) True name fraud data filter and/or profile/model (for
example, second party fraud or third party fraud)--assuming another
person's identity in order to open a new credit account. This is
typically referred to as "second party" or "third party" fraud.
Second party fraud (or familiar fraud) is generally committed by
someone known by or close to a genuine customer, usually a relative
or employee. Third party fraud is generally fraud committed by an
unrelated third party.
[0036] e) Credit manipulation data filter and/or profile/model (for
example, first party fraud)--providing false information to obtain
credit on more favorable terms.
[0037] Because the accounts for the never-pay population tend to
have above average balance amounts, the losses attributed to such
accounts are higher than the losses attributed to normal bad credit
accounts. To identify and/or limit the liability incurred by the
above, methods and systems are disclosed herein to identify the
never-pay population using a never-pay data filters/models and
scoring system that complements risk scores.
[0038] With reference to FIG. 1, there is illustrated an embodiment
of a block diagram of a computing system 100 that is in
communication with a network 160 and various devices that are also
in communication with the network 160. The computing system 100 may
be used to implement certain systems and methods described herein.
For example, in an embodiment the computing system 100 may be
configured to receive financial and demographic information
regarding individuals and generate models to apply to data of the
individuals. The functionality provided for in the components and
modules of computing system 100 may be combined into fewer
components and modules or further separated into additional
components and modules.
[0039] The computing system 100 includes, for example, a personal
computer that is IBM, Macintosh, or Linux/Unix compatible. In an
embodiment, the computing device comprises a server, a laptop
computer, a cell phone, a personal digital assistant, a kiosk, or
an audio player, for example. In an embodiment, the exemplary
computing system 100 includes a central processing unit ("CPU")
105, which may include a conventional microprocessor. The computing
system 100 further includes a memory 130, such as, for example,
random access memory ("RAM") for temporary storage of information
and a read only memory ("ROM") for permanent storage of
information, and a mass storage device 120, such as, for example, a
hard drive, diskette, or optical media storage device. Typically,
the modules of the computing system 100 are connected to the
computer using a standards based bus system. In different
embodiments, the standards based bus system could be Peripheral
Component Interconnect (PCI), Microchannel, SCSI, Industrial
Standard Architecture (ISA) and Extended ISA (EISA) architectures,
for example.
[0040] The computing system 100 is generally controlled and
coordinated by operating system software, such as, for example,
Windows 95, Windows 98, Windows NT, Windows 2000, Windows XP,
Windows Vista, Linux, SunOS, Solaris, or other compatible operating
systems. In Macintosh systems, the operating system may be any
available operating system, such as, for example, MAC OS X. In
other embodiments, the computing system 100 may be controlled by a
proprietary operating system. Conventional operating systems
control and schedule computer processes for execution, perform
memory management, provide file system, networking, and I/O
services, and provide a user interface, such as, for example, a
graphical user interface ("GUI"), among other things.
[0041] The exemplary computing system 100 includes one or more
commonly available input/output (I/O) devices and interfaces 110,
such as, for example, a keyboard, mouse, touchpad, and printer. In
an embodiment, the I/O devices and interfaces 110 include one or
more display device, such as, for example, a monitor, that allows
the visual presentation of data to a user. More particularly, a
display device provides for the presentation of GUIs, application
software data, and multimedia presentations, for example. The
computing system 100 may also include one or more multimedia
devices 140, such as, for example, speakers, video cards, graphics
accelerators, and microphones, for example.
[0042] In the embodiment of FIG. 1, the I/O devices and interfaces
110 provide a communication interface to various external devices.
In the embodiment of FIG. 1, the computing system 100 is coupled to
a network 160, such as, for example, a LAN, WAN, or the Internet,
for example, via a wired, wireless, or combination of wired and
wireless, communication link 115. The network 160 communicates with
various computing devices and/or other electronic devices via wired
or wireless communication links. In the exemplary embodiment of
FIG. 1, the network 160 is coupled to a credit database 162, a
demographic data source 166, such as, for example, a government
public information database, and a customer 164, such as, for
example, a financial institution that is interested in the
financial opportunity associated with particular individual. The
information supplied by the various data sources may include credit
data, demographic data, application information, product terms,
accounts receivable data, and financial statements, for example. In
addition to the devices that are illustrated in FIG. 1, the network
160 may communicate with other data sources or other computing
devices. In addition, the data sources may include one or more
internal and/or external data sources. In some embodiments, one or
more of the databases or data sources may be implemented using a
relational database, such as, for example, Sybase, Oracle, CodeBase
and Microsoft.RTM. SQL Server as well as other types of databases
such as, for example, a flat file database, an entity-relationship
database, and object-oriented database, and/or a record-based
database.
[0043] In the embodiment of FIG. 1, the computing system 100 also
includes an application module that may be executed by the CPU 105.
In the embodiment of FIG. 1, the application module includes a
never-pay module 150, which is discussed in further detail below.
This module may include, by way of example, components, such as,
for example, software components, object-oriented software
components, class components and task components, processes,
functions, attributes, procedures, subroutines, segments of program
code, drivers, firmware, microcode, circuitry, data, databases,
data structures, tables, arrays, and variables.
[0044] In the embodiments described herein, the computing system
100 is configured to execute the never-pay module 150, among
others, in order to create models/profiles and/or to provide
assessment information regarding certain customers, individuals or
entities. For example, in an embodiment the computing system 100
creates models that determine the propensity of an individual to be
a never-pay record and assesses a never-pay score of an individual
or customer that comprises a never-pay record or comprises
attributes of a never-pay model. As another example, in an
embodiment the computing system 100 applies the created models to
determine the propensity of a particular individual/customer or set
of individuals/customers to be a never-pay record and assesses the
never-pay score of the individual/customer or set of
individuals/customers assessed or deemed to be never-pay records.
Various other types of scores, related to other types of market
opportunities, may also be generated by the computing system 100.
As noted above, although the description provided herein refers to
individuals or customers, the terms individual and customer should
be interpreted to include applicants, or groups of individuals or
customers or applicants, such as, for example, married couples or
domestic partners, organizations, and business entities.
[0045] FIG. 2 depicts a diagram illustrating that in another
embodiment the credit database 162 comprises data and/or bureau
data obtained from various data sources, including but not limited
to tradeline data 210, public records data 220, the Experian.RTM.
FileOne.sup.SM database 230, and external client data 240. Public
records data can include without limitation court house records,
litigation records, tax data, recorded liens, foreclosure data,
bankruptcy data, driving records data, police records data,
criminal records data, personal data from public data sources (for
example, newspapers, internet pages, for example, blogs, or the
like). In addition, the data may include externally stored and/or
internally stored data. In certain embodiments, tradeline data 210
and public records data 220 alternatively feed into the
FileOne.sup.SM database 230. The credit database 162 can comprise
only a subset of the data available from the various data sources
set forth above.
[0046] Referring to FIG. 3, there is depicted another embodiment of
a flowchart illustrating one method (for example, a computer
implemented method) of analyzing bureau data, tradeline data,
and/or other data (for example, historical balance and credit
limits for a period of time, such as, for example, a twenty-four
month period) to create never-pay data filters, models and/or
profiles. The method can be performed on real-time, batch,
periodic, and/or delayed basis for individual records or a
plurality of records. The exemplary method may be stored as a
process accessible by the never-pay module 150 and/or other
components of the computing system 100. Depending on the
embodiment, certain of the blocks described below may be removed,
others may be added, and the sequence of the blocks may be
altered.
[0047] With reference to FIG. 3, the method at block 309 is
initiated, and the never-pay data filters/models generation system
identifies the never-pay records/data at block 310. In an
embodiment, the never-pay records data includes without limitation
consumer demographic, credit, and other data (for example, bureau
data, tradeline data, historical balance data for a period of time,
credit limits data for a period of time, or the like). The
identified never-pay records data can also include without
limitation archived data or a random selection of current data. The
never-pay records/data may come from various data sources,
including those discussed above with reference to FIGS. 1 and 2. As
those of skill in the art will recognize, specific criteria for
being categorized as a never-pay record may vary greatly and may be
based on a variety of possible data types and different ways of
weighing the data. At block 320, the never-pay records are tracked
over a period of time. This tracking may include without limitation
real time tracking as well as selecting records/data from a
previous time frame. In certain embodiments, tracking occurs by
analyzing records at one point in time, and then analyzing the same
records at another point in time.
[0048] In FIG. 3 at block 330, a data filter, model, and/or profile
is developed based on the tracked records, which determines the
propensity of an individual/customer to become a never-pay record,
for example, a first, second, third, or other payment default. In
an embodiment, the development of the data filter, model, and/or
profile comprises identifying consumer characteristics, attributes,
or segmentations that are statistically correlated (for example, a
statistically significant correlation) with the occurrence of a
never-pay record. In an embodiment, the development of the data
filter, model, and/or profile comprises developing a set of
heuristic rules, filters, and/or electronic data screens to
determine and/or identify and/or predict which consumer profiles
would be classified as a never-pay consumer based on various data,
such as, for example, bureau data, tradeline data, historical
balance data for a period of time, credit limits data for a period
of time, or the like. The development of data filters, models,
and/or profiles can also comprise developing a set of heuristic
rules, filters, and/or electronic data screens to determine and/or
identify and/or predict which identified never-pay tradelines are
attributable to identity theft based on using bureau data, consumer
identification data, and/or the like. It is recognized that other
embodiments of FIG. 3 may be used. For example, the method of FIG.
3 could be repeatedly performed to create multiple never-pay data
filters, models, and/or profiles.
[0049] Referring to FIG. 4, there is depicted another embodiment of
a flowchart illustrating a method (for example, a computer
implemented method) of analyzing data to apply never-pay data
filters, models, and/or profiles to assess the propensity of a
customer to become a never-pay record. The exemplary method may be
stored as a process accessible by the never-pay module 150 and/or
other components of the computing system 100. Depending on the
embodiment, certain of the blocks described below may be removed,
others may be added, and the sequence of the blocks may be
altered.
[0050] With reference to FIG. 4, the method is initiated at block
409, and the never-pay data filters/models application system at
block 410 selects or receives consumer(s) information and data
wherein analysis is performed on the consumer(s). In certain
embodiments, block 410 also includes the step of obtaining credit
data, bureau data, tradeline data, and/or other data from the
credit database 162. At block 420, the never-pay data
filters/models application system analyzes the obtained credit data
by applying the developed data filter(s), model(s), and/or
profile(s) from block 330 to the obtained credit data to determine
if the consumer(s) exhibits characteristics and/or attributes of a
never-pay record. Based on the analysis completed at block 420, a
score is determined at block 430 to predict the likelihood that the
consumer(s) is a never-pay record. In an embodiment, the never-pay
data filters/models application system at block 420 can select an
appropriate data filter from a plurality of filters stored in a
data filter repository, wherein the selection of an appropriate
data filter can be based on various factors such as price, speed of
response, geographic region, the clients account, or the like. At
block 440, the determined never-pay score is sent to the user or
another module, system, network, or the like.
[0051] Referring to FIG. 5, there is depicted an embodiment of a
flowchart illustrating a method (for example, a computer
implemented method) wherein multiple never-pay data filters, models
and/or profiles are applied to the data (for example, the credit
data, tradeline data, demographic data, or the like) of a
consumer(s) to determine an aggregate never-pay score. In the
illustrated embodiment, the never-pay data filters, models, and/or
profiles include, but are not limited to, the credit risk profile,
the no intent to pay profile, the synthetic credit profile, or the
like. In certain embodiments, different values are combined to form
the aggregate never-pay score depending on whether the data
exhibits attributes of a particular never-pay profile. For example,
if the credit data exhibits attributes or matches the no intent to
pay profile then the value of Y is added to the aggregate never-pay
score whereas if the credit data exhibits attributes or matches the
credit risk profile then only a value of X is added to the
aggregate credit score.
[0052] In the illustrated embodiment depicted in FIG. 5, the
never-pay data filters/models application system receives
individual(s)/customer(s) data, including without limitation
identification and/or demographic information/data about the
individual(s)/customer(s). At block 504, never-pay data
filters/models application system uses the identification and/or
demographic information/data to retrieve the credit data of the
individual(s)/customer(s) from credit report database 506, which in
an embodiment is the credit database 162 illustrated in FIG. 1 and
FIG. 2. At block 508, the identification/demographic
information/data and/or the credit data of the
individual(s)/customer(s) is analyzed, compared with, or passed
through the credit risk data filter, model, and/or profile to
determine whether the individual(s)/customer(s) exhibits the
characteristics, attributes, and/or qualities of a credit risk
profile. For example, the credit risk data filter, model, and/or
profile can determine whether the individual(s)/customer(s)
exhibits a VantageScore.sup.SM or other score below a certain
threshold, or is past due in certain accounts, or is bankrupt, or
has committed fraud, or the like. If at block 514 the
identification/demographic information/data and/or the credit data
of the individual(s)/customer(s) matches the credit risk data
filter, model, and/or profile 508 then the never-pay data
filters/models application system assigns a score to the
individual(s)/customer(s), wherein certain embodiments the assigned
score is based on how closely the individual(s)/customer(s) matches
the credit risk data filter, model, and/or profile.
[0053] Referring to FIG. 5 at block 520, the never-pay data
filters/models application system determines a weighting factor to
apply to the credit risk profile score. In an embodiment, the
weighting factor is predetermined or static, and in another
embodiment, the weighting factor is dynamically determined (for
example, the weighting factor is dynamically determined based on
whether the individual(s)/customer(s) matches other data filters,
models, and/or profiles, or whether the data filter, model, or
profile has been recently updated, or the like). If at block 514
the identification/demographic information/data and/or the credit
data of the individual(s)/customer(s) does not match the credit
risk data filter, model, and/or profile 508 then no score is added
to the aggregate never-pay score.
[0054] In FIG. 5 at block 510, the identification/demographic
information/data and/or the credit data of the
individual(s)/customer(s) is analyzed, compared with, or passed
through the no intent to pay data filter, model, and/or profile to
determine whether the individual(s)/customer(s) exhibits the
characteristics, attributes, and/or qualities of a consumer that
has no intent or substantially no intent to make a payment on the
account. For example, the no intent to pay data filter, model,
and/or profile can analyze the consumer's prior behavioral patterns
to determine whether the consumer has sought and obtained credit
and never paid the debt obligation, or analyze whether the current
behavioral patterns of the consumer exhibit an intent never to pay
the debt obligation (for example, intent can be exhibited by a
consumer's recent bankruptcies or high number of recent
delinquencies or the like). If at block 516 the
identification/demographic information/data and/or the credit data
of the individual(s)/customer(s) matches the no intent to pay data
filter, model, and/or profile 510 then the never-pay data
filters/models application system assigns a score to the
individual(s)/customer(s), wherein certain embodiments the assigned
score is based on how closely the individual(s)/customer(s) matches
the no intent to pay data filter, model, and/or profile.
[0055] Referring to FIG. 5 at block 520, the never-pay data
filters/models application system determines a weighting factor to
apply to the no intent to pay profile score. In an embodiment, the
weighting factor is predetermined or static, and in another
embodiment, the weighting factor is dynamically determined (for
example, the weighting factor is dynamically determined based on
whether the individual(s)/customer(s) matches other data filter,
model, or profile, or whether the data filter, model, or profile
has been recently updated, or the like). If at block 516 the
identification/demographic information/data and/or the credit data
of the individual(s)/customer(s) does not match the no intent to
pay data filter, model, and/or profile 510 then no score is added
to the aggregate never-pay score.
[0056] In FIG. 5 at block 512, the identification/demographic
information/data and/or the credit data of the
individual(s)/customer(s) is analyzed, compared with, or passed
through the synthetic credit data filter, model, and/or profile to
determine whether the individual(s)/customer(s) exhibits the
characteristics, attributes, and/or qualities of a consumer that
has combined real and fictitious identification and credit data in
order to establish a consumer credit profile. For example, the
never-pay data filters/models application system can compare the
data inputted in a credit application form created by the
individual(s)/customer(s) with the credit and demographic data
stored in the credit report database 506 to identify real and
fictitious identification data and credit data. If at block 518 the
identification/demographic information/data and/or the credit data
of the individual(s)/customer(s) matches the synthetic credit data
filter, model, and/or profile 512 then the never-pay data
filters/models application system assigns a score to the
individual(s)/customer(s), wherein certain embodiments the assigned
score is based on how closely the individual(s)/customer(s) matches
the synthetic credit data filter, model, and/or profile.
[0057] Referring to FIG. 5 at block 520, the never-pay data
filters/models application system determines a weighting factor to
apply to the synthetic credit profile score. In an embodiment, the
weighting factor is predetermined or static, and in another
embodiment, the weighting factor is dynamically determined (for
example, the weighting factor is dynamically determined based on
whether the individual(s)/customer(s) matches other data filter,
model, or profile, or whether the data filter, model, or profile
has been recently updated, or the like). If at block 518 the
identification/demographic information/data and/or the credit data
of the individual(s)/customer(s) does not match the synthetic
credit data filter, model, and/or profile 512 then no score is
added to the aggregate never-pay score.
[0058] With reference to FIG. 5, in an embodiment, the weighting
factor determination module 520 identifies all the various
never-pay profiles that the consumer matches and then determines
the unique weighting factor to apply to each of the profile scores.
The assigned unique weighting factor is applied to the profile
score at block 522 and the adjusted profile scores are summed at
block 530 to generate or output an aggregate never-pay score for
the consumer(s) at block 532.
[0059] FIG. 5A depicts an embodiment of applying the method
illustrated in FIG. 5 to determine an aggregate never-pay score for
an individual named Jane. In this example, Jane's credit data
exhibits certain qualities, characteristics, and/or attributes of
the credit risk data filter, model, and/or profile. At block 514,
based on the level of match or similarity of Jane's credit data to
the credit risk data filter, model, and/or profile, the system
assigned Jane a first never-pay score of 5 out of 100 possible
points. At block 516, based on the level of match or similarity of
Jane's credit data to the no intent to pay data filter, model,
and/or profile, the system assigned Jane a second never-pay score
of 0 out of 100 possible points, indicating that Jane did not
exhibit any or only a few qualities, characteristics, or attributes
of the no intent to pay profile. At block 518, based on the level
of match or similarity of Jane's credit data to the synthetic
credit data filter, model, and/or profile, the system assigned Jane
a third never-pay score of 20 out of 100 possible points. The
weighting factor determination module 520 analyzes which data
filters were triggered or matched with Jane's credit data and
determines an appropriate weighting factor to assign to each
never-pay score. Here, this illustrative example, the weighting
factor determination module 520 assigned a factor of 10 to the
credit risk data filter and a factor of 4 to the synthetic credit
data filter, indicating that the credit risk data filter is a
better predictor than the synthetic credit data filter of Jane's
intent to never make a payment. The individual never-pays scores
are combined to generate an aggregate never-pay score at blocks 530
and 532.
[0060] FIG. 6 is flowchart diagram illustrating an embodiment
wherein other data filters, models, and/or profiles are applied to
the credit data of an individual(s)/customers(s) to determine an
aggregate never-pay score. In the illustrated embodiment, the
never-pay data filters, models, and/or profiles include but are not
limited to the first party fraud profile, the second/third party
profile, the no intent to pay profile, or the like. In certain
embodiments, different values are added to the aggregate never-pay
score depending on whether the credit data exhibits attributes of a
particular never-pay profile.
[0061] With reference to FIG. 6 at block 608, the
identification/demographic information/data and/or the credit data
of the individual(s)/customer(s) is analyzed, compared with, or
passed through the first party data filter, model, and/or profile
to determine whether the individual(s)/customer(s) exhibits the
characteristics, attributes, and/or qualities of a first party
profile. For example, the first party data filter, model, and/or
profile can determine whether the individual(s)/customer(s) has
provided false information to obtain credit on more favorable
terms, or the like. If at block 614 the identification/demographic
information/data and/or the credit data of the
individual(s)/customer(s) matches the first party data filter,
model, and/or profile 608 then the never-pay data filters/models
application system assigns a score to the
individual(s)/customer(s), wherein certain embodiments the assigned
score is based on how closely the individual(s)/customer(s) matches
the first party data filter, model, and/or profile. For example,
the assigned score can be increased if a certain number of
application data elements are determined to be false.
[0062] Referring to FIG. 6 at block 620, the never-pay data
filters/models application system determines a weighting factor to
apply to the first party profile score. In an embodiment, the
weighting factor is predetermined or static, and in another
embodiment, the weighting factor is dynamically determined (for
example, the weighting factor is dynamically determined based on
whether the individual(s)/customer(s) matches other data filter,
model, or profile, or whether the data filter, model, or profile
has been recently updated, or the like). If at block 614 the
identification/demographic information/data and/or the credit data
of the individual(s)/customer(s) does not match the first party
data filter, model, and/or profile 608 then no score is added to
the aggregate never-pay score.
[0063] In FIG. 6 at block 610, the identification/demographic
information/data and/or the credit data of the
individual(s)/customer(s) is analyzed, compared with, or passed
through the second party and/or third party data filter, model,
and/or profile to determine whether the individual(s)/customer(s)
exhibits the characteristics, attributes, and/or qualities of a
consumer that assumed another person's identity in order to open a
new credit account. For example, the second party and/or third
party data filter, model, and/or profile can analyze whether a
consumer has assumed the identity of someone known to the consumer
(second party fraud, for example, using a social security number
having a high probability of belonging to another or the observance
of certain patterns or trends in credit bureau data) or has assumed
the identity of someone unrelated to the consumer (third party
fraud). If at block 616 the identification/demographic
information/data and/or the credit data of the
individual(s)/customer(s) matches the second party and/or third
party data filter, model, and/or profile 610 then the never-pay
data filters/models application system assigns a score to the
individual(s)/customer(s), wherein certain embodiments the assigned
score is based on how closely the individual(s)/customer(s) matches
the second party and/or third party data filter, model, and/or
profile.
[0064] Referring to FIG. 6 at block 620, the never-pay data
filters/models application system determines a weighting factor to
apply to the second party and/or third party profile score. In an
embodiment, the weighting factor is predetermined or static, and in
another embodiment, the weighting factor is dynamically determined
(for example, the weighting factor is dynamically determined based
on whether the individual(s)/customer(s) matches other data filter,
model, or profile, or whether the data filter, model, or profile
has been recently updated, or the like). If at block 616 the
identification/demographic information/data and/or the credit data
of the individual(s)/customer(s) does not match the second party
and/or third party data filter, model, and/or profile 610 then no
score is added to the aggregate never-pay score. Other data
filters, models, and/or profiles to determine whether consumers
exhibit the characteristics, attributes, and/or qualities of a
never-pay consumer can be applied by the never-pay data
filters/models application system to generate an aggregate
never-pay score, including without limitation a three-digit zip
code level predictor, wherein, for example, the twenty-five largest
metro areas are identified and a never-pay risk level is associated
with each area. In an embodiment, a data filter, model, and/or
profile is based on a set of predictor attributes or variables that
summarize the risk across multiple attributes, and these summarized
attributes or variables are used in lieu of individual attributes
or variables, such that in certain embodiments, the summarized
attributes or variables are able to preserve predictiveness of the
individual attributes while ensuring a more stable predictor.
[0065] FIG. 7 is flowchart diagram illustrating an embodiment for
applying the aggregate never-pay score to determine whether to
perform a business action or the like. In the illustrated
embodiment, there is illustrated a method wherein the never-pay
score for a particular applicant is applied to determine whether a
denial correspondence or an approval correspondence is sent to the
applicant. As those of skill in the art will recognize, the
illustrated method is applicable for analyzing one applicant at a
time or multiple applicants in a batch or bulk process.
[0066] With reference to FIG. 7, an application for a credit
account or a consumer's credit data is received from a third party
source (for example, an applicant, a financial services firm,
credit card issuer, or the like) at block 702. At block 704 the
applicant's or consumer's credit data is retrieved from the credit
report database 506. At block 706 the never-pay data filters/models
application system applies the never-pay data filters, models,
and/or profiles 708 to determine and/or generate a never-pay score
for the applicant or the consumer, for example, using the systems
and computer implemented methods disclosed with reference to FIGS.
5 and 6. At block 710 the never-pay data filters/models application
system determines whether the never pay score is above a threshold.
In an embodiment, the threshold level is predetermined by the third
party (for example the credit card issuer, or the like), and in
other embodiments, the threshold level is dynamically determined
based on the consumer, period of time (for example, proximity to
end of financial quarter), or proximity to targets or goals (for
example, issue one hundred new approved applications).
[0067] Referring to FIG. 7, if the never-pay score is below the
threshold, then at block 712 the business function to be performed
is to, for example, send a credit application denial correspondence
to the applicant. In an embodiment, if the never-pay score is at or
above the threshold then at block 714 the business function to be
performed is to, for example, perform other analysis or review of
the application or credit data to determine if the applicant
satisfies other criteria at block 716. If the other criteria is
satisfied, then at block 718 the business function to be performed
is to, for example, send a credit application approval
correspondence to the application; otherwise, a credit application
denial correspondence is sent to the application at block 712. In
another embodiment, if the never-pay score is at or above the
threshold then at block 718 the business function to be performed
is to, for example, send a credit application approval
correspondence to the applicant.
[0068] In reference to FIG. 7, there other business functions 712,
718 that can be performed in lieu of the illustrated business
functions. For example, in an embodiment, the never-pay data
filters/models application system is used to determine a deposit
strategy for a new applicant or consumer. For example, a cellular
phone company can use the never-pay data filters/models application
system to determine whether to require a deposit from a new
consumer and/or to determine the amount of the deposit. Credit card
issuers and/or other financial institutions can utilize the
never-pay data filters/models application system to determine
whether a credit limit should be applied to a new consumer and/or
to determine the amount of the credit limit to be applied to a new
consumer. In an embodiment, banks, credit card issuers, and/or
other financial entities can use the never-pay data filters/models
application system (with or without other credit scores or the
like) to determine whether a credit limit should adjusted up or
down for existing consumers. Credit card issuers, banks, and/or
other financial entities can use the never-pay data filters/models
application system in a pre-screen scenario. For example, a credit
card issuer can identity a pool of consumers and use the never-pay
data filters/models application system to identify which consumers
in the pool that should receive a pre-approved credit account
offer. This pre-screen process can be performed on a batch basis or
real-time and/or periodic basis. In an embodiment, the never-pay
data filters/models application system is used to automatically
and/or substantially immediately (for example, on a real-time
basis) determine whether credit should be extended to a consumer.
For example, a credit card issuer can determine whether to approve
an applicant applying online or on the phone for credit. Those
skilled in the art will recognize other business functions that can
be performed with the never-pay data filters/models application
system.
[0069] It is recognized that a variety of scoring methods may be
used including numeric scores where the lower number indicates a
never-pay or where a higher number indicates a never-pay. In
addition, other scores may be used such as, for example, letters
scores (for example A, B, C, D or F) or categories (for example
good, bad), and so forth.
[0070] The never-pay model and/or score can be used in or applied
to several markets including but not limited to the sub-prime
lending market, finance companies, credit unions, savings
institutions, retailers, telecommunications companies, bankcard
issuers, student loans, other markets wherein credit issuers face
risk and/or fraud dilemmas, or any other markets. The never-pay
model and/or score is a useful tool for both risk management by
allowing risk managers to discriminate on the front-end, and for
fraud management by providing fraud managers a better idea on where
to focus their efforts.
[0071] Additionally, the never-pay data filters, models, profiles,
and/or scores can be bundled with a variety of other products and
scores including but not limited to VantageScore.sup.SM or any
other generic score used to improve account acquisition, reduce
account acquisition costs, justify credit line adjustments, predict
loss rates, predict risks such as bankruptcy, fraud, and so forth,
mitigate liability, or the like. A variety of pricing strategies
can be applied to the never-pay model and/or score including but
not limited to using the never-pay model and/or score as a value
added solution, a loss-leader promotion, a free add-on service, a
cross-sell opportunity, or the like. Additionally, the never-pay
model and/or score can be offered at various price points depending
on different factors including but not limited to speed of
response, the number of profiles/models applied, the number of
records reviewed, or the like.
[0072] There are several advantages in using various embodiments of
the never-pay data filters/models generation system including
without limitation: reducing account acquisition costs by helping
to eliminate high-risk prospective consumers that do not fit a
credit criteria; gaining better intelligence on consumer behavior
and motivation by providing access to the most accurate data to
show the most complete picture of the right consumer; gaining
greater control over risk by more accurately and precisely
identifying the never-pay population; automating decision making
processes based on non-judgmental, uniform variables selected based
on the internal data and/or client external data; allowing lenders,
financial entities, and other entities to better discriminate
traditional credit risk more finely to address and meet financial
reporting and risk management regulatory requirements; or the
like.
[0073] In some embodiments, the acts, methods, and processes
described herein are implemented within, or using, software modules
(programs) that are executed by one or more general purpose
computers. The software modules may be stored on or within any
suitable computer-readable medium. It should be understood that the
various steps may alternatively be implemented in-whole or in-part
within specially designed hardware. The skilled artisan will
recognize that not all calculations, analyses and/or optimization
require the use of computers, though any of the above-described
methods, calculations or analyses can be facilitated through the
use of computers.
[0074] Although this invention has been disclosed in the context of
certain preferred embodiments and examples, it will be understood
by those skilled in the art that the present invention extends
beyond the specifically disclosed embodiments to other alternative
embodiments and/or uses of the invention and obvious modifications
and equivalents thereof. Additionally, the skilled artisan will
recognize that any of the above-described methods can be carried
out using any appropriate apparatus. Thus, it is intended that the
scope of the present invention herein disclosed should not be
limited by the particular disclosed embodiments described
above.
* * * * *