WO2002003301A1

WO2002003301A1 - Method for preventing fraudulent financial transactions

Info

Publication number: WO2002003301A1
Application number: PCT/US2001/041226
Authority: WO
Inventors: Becky S. Allen
Original assignee: First Data Corporation
Priority date: 2000-06-29
Filing date: 2001-06-29
Publication date: 2002-01-10
Also published as: AU2001273662A1

Abstract

A name match authorization method for detecting a fraudulent credit card transaction is provided, the method including: a bank-defined setting flag (10), the bank-defined setting flag indicating the appropriate method for routing the authorization process; determining the status of the bank-defined setting flag (16), if the bank-defined setting flag indicates a negative name match authorization mode, then terminate the authorization process (21), if the bank-defined setting flag does not indicate a negative name match authorization mode, then continue the authorization process (22); determining the existence of a Track 1 authorization for an account (42), if the Track 1 is present, continue the name match authorization process, (46) if the Track 1 is not present, then terminate the name match authorization process (62).

Description

METHOD FOR PREVENTING FRAUDULENT FINANCIAL TRANSACTIONS

TECHNICAL FIELD

This invention generally relates to the area of risk management in financial transactions.

BACKGROUND ART

Credit card fraud costs card holders and issuers hundreds of millions of dollars every year. Fraudulent use of credit cards may occur in a variety of ways. For example, the criminal may sort through the victim' s trash for the purpose of extracting credit card receipts or carbons. With the use of the credit card receipts, the thief may use the credit card account numbers illegally. Another example of fraudulent credit card use is where a merchant's clerk makes an imprint from the victim's credit or charge card to make their own personal charges.

In order to combat credit card fraud, Visa International in 1991 came up with Card Verification Value (CVV) where a secret identifying number is encoded into the card's magnetic stripe, in addition to the usual card account details. CVV was relatively inexpensive to implement and the benefits generally outweigh the burdens.

However, a more sophisticated, yet frequent, method of credit card fraud has evolved where the credit card fraud perpetrator removes the data from the magnetic stripe located on the plastic card and replicates the coding from the magnetic stripe to create their own card with the perpetrator's name on the printed on the front of the fraudulent card. For example, the name John Doe appears on the front of the card. The account number 4545-12345-3456 is associated with John Doe's card. A perpetrator creates their own counterfeit card and prints Joe Black on the front of the card and bills to card number 4545-12345-3456. The magnetic stripe information is also altered by replacing John Doe's name with Joe Black's name. Accordingly, the account number and expiration date information are entirely authentic and the perpetrator can use the fraudulent credit card seamlessly. When John Doe eventually receives his monthly statement, he will notice thousands of dollars of charges that he did not make.

Present methods of fraud detection include the verification and authentication of the account number with the card issuer in addition to expiration date verification. However, present day fraud detection methods do not include a verification of the identified name of the card holder.

Accordingly, a need has developed for an automated fraud detection method which verifies the identity of the card holder against the account information.

DISCLOSURE OF INVENTION

It is a principal object of the present invention to provide a method for detecting fraudulent credit card transactions through the verification and matching of the name of the cardholder against the account information.

It is yet another object of the present invention to enhance the authorization process.

It is still another object of the present invention to reduce the incidences of credit card fraud such as sMmming.

It is yet another object of the present invention to increase the accuracy of risk assessment in financial transactions.

More particularly, it is an object of the present invention to provide a method for reducing the number of fraudulent financial transactions, the method of the present invention implements subroutines at transaction processor's host where the first steep of the method is determining the status of the bank-defined setting flag. The bank-defined setting flag is set by the bank. The bank-defined setting flag operates to indicate the appropriate method for routing the authorization process. In determining the status of the bank-defined setting flag, if the bank-defined setting flag indicates a negative name match authorization mode, then the name match authorization process is terminated. The process may then continue to perform a different authorization process. If the bank-defined setting flag does not indicate a negative name match authorization mode, then the authorization process is continued. The authorization process may continue in one of a variety of methods. Regardless, all methods in which the process continues requires a determination as to the existence of a Track 1 name field for the account. If Track 1 name field is not present, then the name match authorization process is terminated and the system may continue to perform an authorization process which may include but is not limited to the validation and verification of the account number and expiration date.

In the event that Track 1 is present, then an external status check is performed on the account in question. The external status check determines whether the card has been reported lost, stolen or closed. If the status indicates any of the aforementioned conditions, then the authorization name match process is terminated.

The method then requires validating the account number and expiration of the account, locating the Track 1 name field, locating the first name sentinel, scanning the Track 1 name field for a last name separator, and scanning the Track 1 name field for the backslash character. The backslash character operates as the delimiter for the end of the last name. If the backslash character is not located, the transaction may be flagged as a name match failure. If the backslash character is located, the name match authorization process continues whereby the last name and the length of the last name are saved to a work area and the last name is isolated in a work area. Once the data is saved to the work area, the system reads the cardholder non- monetary ("nonmon") file to obtain the primary and secondary cardholder names. The nonmon file is the credit history file associated with the account number at issue. This nonmon indicates the available credit, the credit line, outstanding balances, and the primary/secondary cardholders. The saved last name from the Track 1 name field is matched against the primary and secondary name in the transaction processor's database. Once a last name match is made, name match signal is generated at the transaction processor' s host and transmitted to the point of sale device. Assuming the primary and secondary cardholder information was successfully obtained from the nonmon file and the saved last name does not match the cardholder's name on file, then a matching process is performed against the first names of the primary and secondary cardholders. In the event that there is a positive match against the first names, a successful match signal is generated at the host and transmitted to the point of sale device.

These together with other objects of the invention, along with the various features of novelty which characterize the invention, are pointed out with particularity in the claims annexed to and forming part of this disclosure. For a better understanding of the invention, its advantages and objects, reference should be made to the accompanying drawings and descriptive matter in which there is illustrated preferred embodiments of the invention.

BRIEF DESCRIPTION OF DRAWINGS

FIGURE 1 is a flow chart illustrating the preferred embodiment of the method steps of the present invention.

BEST MODE FOR CARRYING OUT THE INVENTION

With reference to Figure 1, a method for reducing credit card fraud is shown. The method of the present system is an enhancement to the authorization process and may be intended to be implemented with other risk models to enhance the authorization process. The method of the present invention is preferably implemented after a determination is made on the external status of the account such as determining if the account is closed or the card is lost/stolen. If all of these conditions are absent, then the method of the present invention may be implemented. The results of this method may be used in conjunction with other risk models which may take into account information such as the location of the purchase, the amount of the purchase and the type of the purchase. The method of the present invention is implemented with the traditional risk models in order to reduce the incidences of fraud such as "sMmming" by verifying the identity of the cardholder's identity against account number and expiration date. The name match authorization method for reducing credit card fraud is performed by matching the name of the card holder against the issuer's or transaction processor's master database. The method is performed through a variety of subroutines residing at the host of the transaction processor. The transaction processor's host is preferably in communication with a plurality of point of sale terminals.

The first step of the method consists of determining the status of a bank- defined setting flag 10. The bank-defined setting flag indicates the appropriate method for routing the authorization process. The bank-defined setting flag informs the host whether the client or merchant wishes to participate in the name match process. In the event the name is not matched, the bank-defined setting flag informs the system what action it should take. For example, the bank-defined setting flag may indicate "0" where a name match should not be performed. Other variables may include the following: 1 - Decline the transaction if the name match fails; 2 - Decline with referral if the name match fails; 3 - Pick up card, electronic only;4 - Decline with High Credit Line Voice Referral; 5 - Perform name match but no action. The first option listed indicated as "1" is where the transaction is declined where the system indicates that the card user name fails to match the name listed in the master database files. The second option listed as "2" requests that the merchant contact the transaction processor in declining the transaction. The third option indicated as "3" is where the credit card must be retained by the merchant. The fourth option listed as "4" is an action where the bank's phone number is passed directly on to the merchant and the merchant must directly contact the bank. The fifth option listed as "5" is an action where the steps to determine whether a match exists between the master database and the card itself are performed but no action is taken in the event of a failed match.

Upon implementing the process, if the bank-defined setting flag indicates a negative name match authorization mode, then the authorization process is terminated. If the bank-defined setting flag does not indicate a negative name match authorization mode, then the authorization process may be continued according to one of the codes indicated above or a similar code. The next steps of the method of the present invention requires a check of the external status of the account 12. The external status of the account tells the transaction processor as to whether the card is reported lost or stolen or the account is closed. In the event that the card is lost/stolen or the account is closed, the authorization name match method will not be performed as authorization in these instances is unnecessary. Once the account number and expiration date of the account have been validated, the Track 1 name field must be located 14. The track 1 name field is a field found on the magnetic stripe. The Track 1 name field typically includes the first and last name of the card holder. Another track on the magnetic stripe is the Track 2. The Track 2 includes the account number, expiration date, service code and the Card Verification Vale (CVV) value. If the Track 1 is not present, then the name match authorization process must be terminated given that the name is not provided on the card and a matching process can not occur.

Once the Track 1 name field has been located, the field must be scanned for the last name separator or a backslash character 16. The backslash character is generally the delimiter for the end of the last name. The lack of a backslash character is indicative of a fraudulent credit card and if the host fails to detect the presence of the backslash character 18, then the transaction is flagged as a name match failure 20.

In the event that a backslash indicator is located 22, the last name of the card holder is located and the last name is saved in addition to the length of the last name 24. An example of the data may appear as (JONES 5 characters). This data is saved to a work area thereby isolating the last name 24. The next step involves reading the cardholder nonmon file to obtain the primary and secondary cardholder names and matching the last name from taken from the Track 1 scan against the primary and secondary name in the database 26.

Where the primary and secondary cardholder names are successfully obtained, then the system compares the saved last name and the length of the name against a database having the cardholder's name on file. If the saved last name matches the cardholder' s name on file 28, then the system returns a successful match signal 32. If the saved last name does not match the cardholder's name on file 30, then the address line may be checked for a match 34. This subroutine reduces the chances of erroneous declines due to cardholder names existing on the address field. In the event that there is a successful match between the address line and the master database files 36, a successful match signal is returned to the calling program. Otherwise, where there is no match between the address line and the name data 42, the first name is scanned from Track 1 42 and matched 44 against the master database files. In scanning the cardholder's name, the system matches the length of the scanned name against the length of the name in the database. By comparing name length, the system reduces the number of erroneously declined transactions due to the insertion of a space in the name field.

With respect to the first name matching process, this process is implemented in order to prevent erroneously declined transactions where the cardholder's last name has been changed due to marriage, divorce or the like. Again, if there is a successful first name match 46, a successful match signal is returned to the calling program. Otherwise, where there is no match against the masterfile 50, the host determines if there are any cross-referenced accounts associated with the initial account 52. Similarly, it must be determined whether the extracted data matches against the cross-referenced account 54. In all cases where there is a failure to match, an audit record may be written indicating no matching name. At that point, the transaction may be flagged as a name match failure 20, 60 and a no name match response may returned to the calling program in lieu of continuing the authorization process.

Upon completing the name match subroutine, the return code is examined for the name match failure and appropriate action is taken according to the previously generated bank-defined setting flag. Examples of codes for the bank- defined setting flag are as follows: 1 - Decline the transaction if the name match fails; 2 - Decline with referral if the name match fails; 3 - Pick up card, electronic only; 4 - Decline with High Credit Line Voice Referral; 5 - Perform name match but no action. The internal reason code created for the name mismatch may indicate that the transaction may not be honored or a referral may be required. In the alternative, the transaction data along with the results of the name match subroutine may be passed onto another authorization process which may include other transaction criteria in authorizing a transaction.

Moreover, in the process of scanning the Track 1 name field for the backslash character, if there is a failure to locate the backslash character 18, the transaction is flagged as having a name match failure 20 and the transaction is associated with a corresponding code for an audit report. The corresponding code (indicated above by way of example) indicates the that the name match failure has occurred and the appropriate action that must be taken. Furthermore, the report may identify the type of match used to verify the transaction. As indicated above, the present invention attempts to match the cardholder's name in a variety of ways, which include but are not limited to: (1) primary cardholder first name match; (2) primary cardholder second name match; (3) backward scanning primary name; (4) backward scanning secondary name; (5) name match in address line; (6) scan primary name to match; (7) scan secondary name; (8) search and match additional cardholder names. The report may further include a statistical report for the particular card base which identifies the quantity of transactions which match, fail, or match via a particular means.

It is also important to note that, in some cases, the transaction processor may prefer to perform the authorization analysis on names having upper case letters only. Accordingly, the above-referenced method may further include the additional step of converting the Track 1 name to upper case letters for purposes of name comparison where the letters of Track 1 name is in lower case letters.

In order to reduce erroneously declined transactions, the method of the present invention locates the first and last name of the card holder even in cases where the card holder's name has been improperly formatted on the magnetic stripe. For example, the cardholder's first and last name are sometimes improperly formatted before the backslash indicator. In this case, the method of the present invention not only includes scanning the Track 1 name field but also includes backward parsing of the name field and further identifying the last name of the cardholder. Again once the last name is properly matched against the last name in the master database files, a successful name match signal is generated and returned to the calling program.

While the preferred embodiment of the invention has been illustrated and described, it is not intended that this embodiment illustrate and describe the only possible form of the 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 among the steps of the recited method without departing from the spirit and scope of the invention.

Claims

WHAT IS CLAIMED IS:

1. A name match authorization method for detecting a fraudulent credit card transaction, the method comprising: determining the status of a bank-defined setting flag, the bank-defined setting flag indicating the appropriate method for routing the authorization process, if the bank-defined setting flag indicates a negative name match authorization mode, then terminate the authorization process, if the bank-defined setting flag does not indicate a negative name match authorization mode, then continue the authorization process; determining the existence of a Track 1 name field , if the Track 1 name field is present, continue the name match authorization process, if the Track 1 name field is not present, then terminate the name match authorization process. determining the external status of the account, the external status of the account including validating the account number and expiration of the account; scanning the Track 1 name field for a last name separator, the backslash character being the delimiter for the end of the last name, if the backslash character is not located, flagging the transaction as a name match failure, if the backslash character is located, continuing the name match authorization process; saving the last name and the length of the last name to a work area and isolating the last name; comparing the saved last name and the length of the name against a database having the cardholder's name on file at a first subroutine, if the saved last name matches the cardholder's name on file, then return a successful match signal and terminate authorization match process, if the saved last name does not match the cardholder's name on file, then proceed to a second subroutine; scanning an address line of the card and comparing the saved last name and length of the name against the address line at the second subroutine, if the saved last name matches the address line, then return a successful match signal and terminate the authorization match process, if the saved last name does not match the address line, then proceed to a third subroutine; reading the cardholder nonmon file to obtain the primary and secondary cardholder names at the third subroutine and matching the Track 1 first name against the primary and secondary name in the database, if the saved first name matches the Track 1 first name, then return a successful name match signal, if the saved first name does not match the Track 1 first name, then return a no match signal and terminate the subroutine; and providing the resulting signal to a risk model.

2. The method of claim 1 wherein the step of scanning the Track

1 name field for the backslash character and failing to locate the back slash character further includes flagging the transaction as a name match failure and identifying the transaction with a code for an audit report.

3. The method of claim 1 wherein the step of scanning the Track 1 name further includes converting the Track 1 name to upper case letters for purposes of name comparison where the Track 1 name is in lower case letters.

4. The method of claim 1 wherein the step of reading the cardholder nonmon file includes backward parsing the name where both the first and last names of the cardholder are before the backslash indicator and identifying the last name of the cardholder, if the last name matches the masterfile, then a successful match signal is generated.

5. The method of claim 1 further including the step of scanning the address lines of the card information to find a match for the cardholder's last name.

6. The method of claim 1 further including the step of matching the scanned first name against the primary and secondary names of the masterfile.

7. The method of claiml further including writing an audit record indicating no match where no match is found and generating a no name match signal.