US20080288385A1

US20080288385A1 - Method and system for preventing card fraud

Info

Publication number: US20080288385A1
Application number: US11/811,299
Authority: US
Inventors: Julie A. Geschwender; Michele Murphy-Houser
Original assignee: First Data Corp
Current assignee: First Data Corp
Priority date: 1998-10-26
Filing date: 2007-06-08
Publication date: 2008-11-20
Also published as: US7337119B1

Abstract

A method and system for preventing card fraud include obtaining card event information of a card user from a provider such as a card issuer, a merchant, a retailer, etc., during a card event between the card user and the provider. The card event information is compared with known fraudulent information stored in a database. An alert is sent to the provider if there is a match between the card event information and the known fraudulent information.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No. 09/425,471, filed Oct. 22, 1999, now U.S. Pat. No. ______; which claims the benefit of U.S. Provisional Application No. 60/105,611, filed Oct. 26, 1998.

BACKGROUND OF THE INVENTION

1. Field of the Invention
The present invention relates to systems and methods for detecting and preventing purchasing card fraud during all phases of a purchasing card life cycle.
2. Background Art
Roughly half a billion transactions with significant, but preventable, fraud potential occur in the United States each year. Purchasing card contact events that can lead to fraudulent occurrences include application processing, card activation, usage, such as mail and phone ordering, and maintenance events, such as address or other information changes. It is estimated that the total cost of fraud is $1.3 million for every one million gross active accounts, or $1.34 in fraud loss per gross active account (Sources: VISA/MC, Credit Card Prevention Sourcebook).
A large portion of this fraud could effectively be addressed though improved identification of known fraudulent names, fraudulent addresses, fraudulent phone numbers, fraudulent social security numbers, and other fraudulent personal information. In fact, a large number of fraud cases are typically perpetrated by repeat offenders or organized rings.
Current tools to combat repeat and organized fraud are still underdeveloped. While there are a myriad of sources for fraud-related information, the various sources focus on differing pieces of personal data and return fraudulent alerts in non-standard formats. In addition to the lack of uniformity of the alert information, current systems lack real time, “near” real time, or via batch functionality. Furthermore, no single comprehensive source exists that is capable of addressing fraud during the many stages of a purchasing card account.

SUMMARY OF THE INVENTION

Therefore, it is an object of the present invention to provide a system and method for facilitating fraud prevention and detection at all stages of a purchasing card life cycle, wherein purchasing cards are defined as credit cards, debit cards, “Smart” cards (having IC chips), retail cards (such as gas cards), and the like.
It is another object of the present invention to provide a single comprehensive database of standardized fraud data from various contributory sources.
It is still another object of the present invention to allow clients to reduce manual processes for fraud detection.
In carrying out the above objects and other objects, the present invention provides a method for preventing card fraud. The method includes obtaining card event information of a card user from a provider during a card event between the card user and the provider. The method further includes comparing the card event information with known fraudulent information stored in a database. The method further includes sending an alert to the card user if there is a match between the card event information and the known fraudulent information.
Further, in carrying out the above objects and other objects, the present invention provides a system for preventing card fraud. The system includes a database for storing known fraudulent information. The system further includes a processor in communication with the database and a provider. The processor receives card event information of a card user from the provider during a card event between the card user and the provider, compares the card event information with the known fraudulent information stored in the database, and sends an alert to the card user if there is a match between the card event information and the known fraudulent information.
In embodiments of the present invention, a central fraud database is created for receiving known fraudulent or “high risk” personal information. The personal information may include fraudulent names, fraudulent addresses, fraudulent phone numbers, fraudulent places of employment, criminal history, and other personal information for example. The central fraud database receives information from a variety of sources including but not limited to proprietary databases, client fraud files, law enforcement, and USPS databases. After a contact event has a occurred the fraud database is scanned for a match between the contact event information and the contents of the fraud database. If a possible fraud match occurs the system sends a fraud alert to the client or user of the database. The present invention has many advantages including the capability to send fraud alerts in real time, “near” real time, or via batch to clients thus reducing or eliminating damage caused by potential purchasing card fraud.
The above objects and other objects, features, and advantages of the present invention are readily apparent from the following detailed description of the preferred embodiment(s) when taken in connection with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a schematic representation of a purchasing card fraud detection system in accordance with an embodiment of the present invention;

FIG. 2 illustrates a flow diagram of a method of detecting purchasing card fraud in accordance with an embodiment of the present invention;

FIG. 3 illustrates a flow diagram of a fraud matching process in accordance with an embodiment of the present invention; and

FIG. 4 illustrates a schematic representation of a fraud database architecture in accordance with an embodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT(S)

U.S. application Ser. No. 09/425,471, filed Oct. 22, 1999, now U.S. Pat. No. ______, is hereby incorporated by reference in its entirety.
Systems and methods in accordance with embodiments of the present invention facilitate fraud prevention and detection for all contact events during a purchasing card life cycle. Such contact events include: 1) application processing; 2) card activation; 3) cardholder usage, including mail and telephone orders; and 4) maintenance events, such as name and address changes, PIN changes, plastic requests, and credit line increases.
Referring now to FIG. 1, a system in accordance with an embodiment of the present invention includes a single, comprehensive risk (or fraud) database 10 for the detection of purchasing card fraud. Risk database 10 may include information from various sources 12, as will be described below. Risk database 10 may be server-based having connectivity, via a local area network 14 or other network, to a mainframe 16. Mainframe 16 is provided for on-line transactions involving the various contact events 18 described above. Clients 20 are provided with connectivity to risk database 10 for file transfer and general access, and are also provided with connectivity to mainframe 16 (graphical user interface, dummy terminal, or the like) for receipt of fraud alerts and queue information. An optional, more limited database (not shown) could be provided for non-contributors to risk database 10. A backup server may be provided.
The system possesses the technical functionality to pool data from multiple sources in multiple formats and to standardize reporting structure guidelines, enabling risk database 10 to function for many types of transactions or contact events 18. In addition, the system provides the ability to query in real time, “near” real time, or via batch with on-line interfaces to the mainframe transactions. Limited client 20 resources are required for access.
In an embodiment, at mainframe 16 level, a daily queue statistics report is developed at client 20 level to identify all accounts matching risk database 10, including the source of the data match. Furthermore, at the server level, reports are generated which track contributor statistics. In addition, reporting is developed to track client statistics on a query basis, such as by the number of record transactions queried against risk database 10, or by the number of records with a data match.
Possible sources for consortium fraud database 10 include client databases, credit card issuer databases, credit bureau databases, research and investigation fraud files, ANI risk databases, the U.S. Postal Service NRI database, Account Takeover modeling/scoring, the Social Security Administration, the Department of Motor Vehicles, Western Union, Telecheck, the American Business List, law enforcement, court and public information records, phone directories, and direct mail surveys.
From such sources, the available data includes, but is not limited to: 1) personal information, such as addresses, phone numbers, and social security numbers used in known frauds; 2) valid US addresses and their nature, i.e. residential, commercial, or vacant; 3) valid address/name combinations; 4) high risk zip codes; 5) public information, such as bankruptcy filings, tax liens, and civil judgments; and 6) consumer and purchase data.
The proposed data element structure within risk database 10 includes at least the following:
1. Names of fraudulent or potentially fraudulent (“high risk”) primary, secondary, and additional cardholders in the form of first name, last name, and middle initial.
2. Fraudulent or potentially fraudulent (“high risk”) home and business addresses, including P.O. Box, city, state, and zip code.
3. Fraudulent or potentially fraudulent (“high risk”) home and business telephone numbers.
4. Fraudulent or potentially fraudulent (“high risk”) social security numbers of primary, secondary, and additional cardholders.
Risk database 10 acts as a central repository for fraud data to be queried against by lenders and adjacent market users. Potential primary users or clients include bank card issuers, non-bank card issuers, potential card issuers, oil card issuers, merchants, and retailers. Possible secondary users include phone companies, DDA Account banks, and utility companies, among others.
A method of detecting potential purchasing card fraud in accordance with an embodiment of the present invention is outlined in the flow diagram of FIG. 2. The method includes obtaining contact event information at mainframe 16, as represented by block 50, and comparing contact event 18 information to fraud information stored in risk database 10, as represented by block 52. If a match is found between contact event 18 information and the fraud information, the method further includes issuing an on-line alert to client 20 and queuing the information for manual review by the particular client, as represented by block 54. If a match does not occur, then client 20 is notified as such and communication with risk database 10 is concluded, as represented by block 56. Optionally, a fraud match may be scored, as represented by block 58 and as will be explained below. If client 20 does not wish to receive a score then communication with the database is concluded, as represented by block 60. However, if client 20 has elected to receive a match score, a scorecard is generated and sent to client 20, as represented by block 62 and then communication with risk database 10 is terminated at block 64.
Within the system, contact event 18 transactions are preferably structured to create automatic queries which compare account record data elements against the fraud information stored in risk database 10. If a match is found between the account data and the fraud data, then the system generates an alert message in real time, “near” real time, or via batch to the queue. In addition, the account record is sent to an on-line queue to be monitored and/or manually worked by client 20. Upon entry to the queue, contact event 18 transaction is suspended or placed on hold until manual follow-up is completed. Contact event 18 information may for example be purged from the database.
An additional feature is to offer clients 20 the option of having matched fraud data records “scored” to assist in the decision/action processes when a record is queued. Preferably, a generic suite of scorecards is provided, while also allowing client-defined scorecards to be developed and implemented. In an embodiment, a scorecard is provided which predicts the likelihood of a fraudulent takeover of an existing, active, or inactive cardholder account.
The following attributes of systems and methods in accordance with embodiments of the present invention are thus possibly provided to facilitate fraud detection at all stages of a purchasing card life cycle:

- Application Processing
- Card Activation
- Cardholder Usage/Maintenance
- Other Transaction or Contact Events: Priority Non-Mons: PIN changes, plastic requests, credit line increases and changes to the account record.

Components of systems and methods in accordance with embodiments of the present invention include:

- Consortium Data Warehouse
- Fraud Scoring
- Actioning (Alerts to On-Line Screens)
- Queuing for Manual Review

The Matching Process

As shown in FIG. 3, selected non-monetary transactions may be structured to create queries which compare account record data elements against Consortium Fraud Database 10. For example, during an account entry transaction 18 (application processing, card activation, mail/phone order, address change, and the like) could automatically compare key application data elements against the Data Warehouse or Risk Database 10. If a match is found, as represented by block 82, between the account and fraud database 10, then an alert message 84 is generated in real time, “near” real time, or via batch. In addition, the account record may be sent to an on-line queue 86 to be monitored and/or manually worked by the client. Upon entry to the queue, the non-monetary transactions would be suspended or placed on hold until manual follow up is completed. In the case of new account entries and batch-entered new accounts, the accounts may be built on the system, however, plastic generation would be suspended.
Information residing within the queue includes the account record information, the reason for the alert (i.e., potential fraudulent name, address, social security number, or phone number), and the contributing source of the matched data. This process helps to reduce responsibility/liability for data integrity.

Scoring of Matched Data

In an embodiment of the present invention, clients have the option of having matched fraud data records “scored” to assist in the decision/action processes when a record is queued, as represented by block 88. This should provide business opportunities to build the appropriate scorecard logic. Accordingly, a generic suite of scorecards 90 may be implemented as well as client-defined scorecards 92.

Consortium Contributors

All consortium contributors are allowed access to the entire data warehouse. Usage incentives may be provided for “global” contributors. An example of a usage incentive may be reduced fees for accessing fraud database 10. Other incentives include partial to full access to information contained in fraud database 10.

Non-Consortium User

A non-contributor to the consortium may be offered access to information that the database manager may have purchased or provided in a non-consortium database 100. Otherwise non-contributors may be restricted from information provided by “global” contributors to Risk Consortium Database 10.

Summary of Benefits and Critical Needs Met

- Provides a single source of uniform data from various contributor business sources;
- Increases the effectiveness of fraud detection efforts;
- Allows clients to reduce current manual processes for fraud identification and actioning;
- Pools data across the client base to improve identification of repeat offenders.

Consortium Risk Data Warehouse

Consortium data warehouse 10 (i.e., risk or fraud database 10) contains data contributed from various business sources 110 including, but not limited to:

- Clients;
- Research and Investigation Fraud Files (Fraud App's and Account takeovers (type lost 3,5,8));
- Customer Service Fraud File Database;
- Card Activation ANI Risk Database;
- Postal NRI Database (high risk Zip Codes);
- Social Security Administration compromised SSN's;
- International Association of Financial Crimes Investigators;
- Cellular or Pay Phone Numbers/Numbers used fraudulently;
- Western Union Fraud Data;
- American Business List (prison addresses, hospitals, etc.);
- Account takeover modeling/scoring;
- Potential model for Skimmin;
- American Correctional Association;
- Lexis/Nexis.

Proposed Data Element Structure

As depicted in FIG. 4, the data element structure 200 may include:

- Name (Primary and Secondary and additional): First, Last, Middle Initial;
- Address: Home, Business (including PO Box);
- City;
- State;
- Zip Code;
- Phone: Home, Business;
- Social Security Number: Primary, Secondary;
- High Risk Zip Codes (NRI data); and
- Known fraudulent accounts determined by type lost.

Therefore, systems and methods in accordance with embodiments of the present invention provide a single source of uniform data from various contributor business sources 210, increase the effectiveness of fraud detection efforts, allow clients 212 to reduce current manual processes for fraud identification and actioning, and allow pooling of data across the client base to improve the identification of repeat offenders.
While embodiments of the present invention have been illustrated and described, it is not intended that these embodiments illustrate and describe all possible forms of the present invention. Rather, the words used in the specification are words of description rather than limitation, and it is understood that various changes may be made without departing from the spirit and scope of the present invention.

Claims

1. A method for preventing card fraud, the method comprising:

obtaining card event information of a card user from a provider during a card event between the card user and the provider;

comparing the card event information with known fraudulent information stored in a database; and

sending an alert to the provider if there is a match between the card event information and the known fraudulent information.

2. The method of claim 1 wherein:

obtaining card event information of the card user from the provider comprises obtaining at least one of a name of the card user, a social security number of the card user, and an address of the card user.

3. The method of claim 1 further comprising:

receiving known fraudulent information by the database for storage therein from at least one source of known fraudulent information.

4. The method of claim 1 wherein:

the card event involves a card application process between the card user and the provider.

5. The method of claim 1 wherein:

the card event involves a card activation process between the card user and the provider.

6. The method of claim 1 wherein:

the card event involves either a card mail order transaction or a card phone order transaction between the card user and the provider.

7. The method of claim 1 wherein:

the card event involves an address change process between the card user and the provider.

8. The method of claim 1 further comprising:

suspending the card event if there is a match between the card event information and the known fraudulent information.

9. The method of claim 1 wherein:

sending an alert to the provider comprises sending the alert either in real time or via batch to the provider.

10. The method of claim 1 wherein:

the provider is either a card issuer, a merchant, or a service provider.

11. A system for preventing card fraud, the system comprising:

a database for storing known fraudulent information; and

a processor in communication with the database and a provider;

wherein the processor receives card event information of a card user from the provider during a card event between the card user and the provider, compares the card event information with the known fraudulent information stored in the database, and sends an alert to the provider if there is a match between the card event information and the known fraudulent information.

12. The system of claim 11 wherein:

the card event information includes at least one of a name of the card user, a social security number of the card user, and an address of the card user.

13. The system of claim 11 further comprising:

at least one source of known fraudulent information;

wherein the database receives known fraudulent information for storage therein from the at least one source of known fraudulent information.

14. The system of claim 11 wherein:

15. The system of claim 11 wherein:

16. The system of claim 11 wherein:

17. The system of claim 11 wherein:

18. The system of claim 1 wherein:

the processor suspends the card event if there is a match between the card event information and the known fraudulent information.

19. The system of claim 11 wherein:

the processor sends the alert to the provider either in real time or via batch.

20. The system of claim 11 wherein:

the provider is either a card issuer, a merchant, or a service provider.