Patent Application
20140129441
The present invention generally relates to systems and methods for enabling an issuer financial institution (FI) to contact a consumer (cardholder) concerning a questionable or possibly fraudulent purchase transaction via a non-intrusive notification transmitted to the consumer's mobile device. In response to the notification, the cardholder can accept or decline the purchase transaction by interacting with one or more menus provided on his or her mobile device.
Payment cards such as credit or debit cards are ubiquitous and for decades such cards have included a magnetic stripe on which the relevant account number is stored. To consummate a purchase transaction with such a card, the card is swiped through a magnetic stripe reader that is part of the point of sale (POS) terminal. The reader reads the account number from the magnetic stripe. The account number is then used to route a transaction authorization request that is initiated by the POS terminal.
A prominent payment card system is operated by the assignee hereof, MasterCard International Incorporated, and by its member financial institutions. In a typical purchase transaction, a consumer visits a retail store operated by a merchant, selects goods that he or she wishes to purchase, carries the goods to the merchant's POS terminal, and presents his or her payment card. The POS terminal reads data such as the customer's payment card account number from the payment card and sends an authorization request to an acquirer financial institution (FI) with which the merchant has a relationship. The authorization request typically includes data such as the payment card account number, the amount of the transaction, the time of day, some details of the merchant's store, and other information. The authorization request is routed via a payment card system (which may be, for example, the well-known Banknet system operated by the assignee hereof) to the issuer financial institution (FI) that issued the customer's payment card. If all is in order, the issuer FI transmits a favorable authorization response to the POS terminal through the payment card system and via the acquirer FI. The transaction at the POS terminal is then completed and the customer leaves the store with the goods. A subsequent clearing transaction initiated by the merchant results in a transfer of the purchase transaction amount from the customer's payment card account to an account that belongs to the merchant.
A drive for greater convenience and more rapid transactions at POS terminals has resulted in the development of payment cards that allow the account number to be automatically read from the card by radio frequency (RF) communication between the card and a proximity reader which may be incorporated with the POS terminal. Such cards are often referred to as “proximity payment cards” or “contactless payment cards”, and contain a radio frequency identification (RFID) integrated circuit (IC) or tag that is embedded in the card body. A suitable antenna is also embedded in the card body and is connected to the RFID IC (or chip) to allow the chip to receive and transmit data by RF communication via the antenna. In typical arrangements, the RFID IC is powered by an RF interrogation signal that is transmitted by the proximity reader and received by the card antenna.
MasterCard International Incorporated, the assignee hereof, has established a widely-used standard known as “PayPass” for interoperability of contactless payment cards and proximity readers. In the PayPass system, at checkout a tiny microchip and a radio antenna embedded in a PayPass-enabled device wirelessly transmits payment details to a PayPass reader when the PayPass-enabled device is brought into close proximity (by “tapping” the device on a pre-set location) to the reader. The proximity reader associated with the POS terminal then verifies the transaction with the issuer FI through, for example, MasterCard's reliable network and indicates approval. The PayPass reader includes a keypad that allows a cardholder to enter a Personal Identification Number (PIN) used by the payment system to authenticate the cardholder. It should be understood, however, that other types of wireless protocols for the wireless exchange of information have been established, such as Near-Field Communication (NFC), for payment applications.
The capabilities of a proximity payment card (or a contactless payment card) have recently been incorporated into portable or mobile devices, thereby turning such mobile devices into contactless payment devices. Such a contactless payment devices typically includes integrated circuitry with the same or similar functionality as the RFID IC of a contactless payment card and include an antenna. Examples of payment-enabled mobile devices include, but are not limited to, mobile telephones, tablet computers, key fobs, portable digital music players, personal digital assistants (PDAs) and the like.
Internet shopping is now common, and online shopping websites and/or merchants encourage online shopping by offering discount prices and by promoting free-shipping or reduced fee shipping options. Internet transactions are typically conducted by consumers entering credit card, debit card and/or gift card data into a checkout screen of a merchant's website (often referred to as “card not present” transactions). Such purchase transaction checkout procedures typically only require a credit card number, expiration date and CVC2 code data entry from the consumer to process a transaction.
Payment card fraud sometimes occurs, and costs financial institutions, consumers and merchants a significant amount of money each year. Thus, financial institutions have increasingly sought to improve security measures including utilizing computer systems that run complex statistical modeling programs to analyze transactions for signs of fraud. In many cases, the fraud-detection programs are “self-learning”, which means that the programs teach themselves over time which behaviors and situations are normal for a particular consumer and which are not by using consumer data such as spending patterns and the like. Some of these anti-fraud programs build up a database of information concerning how, when and where each consumer shops. Such data is then analyzed to determine whether or not a current transaction fits the expected or usual pattern. For new credit card customers, since there is not much information to work with initially, a method called “peer profiling” may be used which compares that new credit card customer's transactions with those made by people of similar age and income who reside in the same or similar geographic area to flag any potential fraudulent activity. Payment card issuers may also impose certain rules on the anti-fraud software to spot potentially fraudulent use of a payment card account. For example, if a few very small transactions are followed by one or more very large transactions then those transactions for that payment card account may be flagged because it has been observed that thieves often “test” a stolen credit card account number with a small purchase before buying something expensive. In another example, if the cardholder logs into his or her bank account from a home computer in California and minutes later someone uses that same cardholder's bank-issued payment card in a shop in Mexico, then that payment card account may be flagged for potential fraudulent activity as it appears that the cardholder is in two places at one time.
When an issuer financial institution or other entity flags a potential fraudulent transaction, the fraud-detection software may be configured to suspend, block or freeze a payment card account until the issuer can contact the cardholder to verify that one or more transactions are not fraudulent. Typically, when a payment card transaction is flagged by an issuer bank's anti-fraud system as possibly being fraudulent, a representative of the issuer bank calls the cardholder by telephone to confirm that the flagged transaction should (or should not) be authorized. However, this process is not always efficient as the cardholder may not be available to pick up the call. Using the example mentioned above concerning a cardholder who has logged into his bank account from a home computer in California and minutes later someone used that same cardholder's bank-issued payment card in a shop in Mexico, if the person using that payment card account in Mexico is the cardholder's daughter who is using an authorized card while on spring break, then she will not be happy that the payment card account has been blocked. Furthermore, if the cardholder is unavailable to receive a telephone call from the issuer financial institution, then the cardholder's daughter can be placed in an uncomfortable and potentially dangerous situation if she cannot complete the transaction or utilize that payment card for another transaction.
Consumers can also be notified about a transaction that has occurred by e-mail to an e-mail account provided by the consumer to his or her payment account issuer, and/or via short-messaging service (SMS) to the cardholder's mobile telephone. (An SMS message is a text message that can be sent from one cell phone to another or from an entity such as a financial institution to a customer's cell phone.) However, an e-mail message may also not adequately protect a cardholder from a fraudulent transaction because he or she may not have internet access at the time of the fraud and thus not have access to e-mail, and some cardholders may decline to utilize SMS message notifications because such messaging can be intrusive. In addition, consumers are leery of receiving bogus fraud alerts, which typically include a fraudulent return phone number and/or link to a fraudulent website, which fraudsters have learned can be a great way to trick cardholders into providing sensitive financial account information.
Thus, there is a need for providing a cardholder with a non-intrusive, secure process for validating a questionable or dubious purchase transaction that has been flagged by an issuer as being potentially fraudulent, and to do so in real-time by using his or her mobile device, such as a mobile telephone. In addition, there is a need for providing a cardholder with a method for securely pre-authorizing purchase transactions from his or her mobile device so that the card issuer financial institution will not flag a particular questionable purchase transaction as being possibly fraudulent.
Features and advantages of some embodiments, and the manner in which the same are accomplished, will become more readily apparent with reference to the following detailed description taken in conjunction with the accompanying drawings, which illustrate exemplary embodiments (not necessarily drawn to scale), wherein:
In general, and for the purpose of introducing concepts of novel embodiments described herein, provided are systems, apparatus and methods for enabling an issuer financial institution (FI) to contact a consumer or an account holder (such as a cardholder) concerning a questionable or possibly fraudulent purchase transaction via a non-intrusive notification transmitted to an application resident on the mobile device of the consumer and/or cardholder. The notified cardholder can then accept or decline the transaction by interacting with one or more menus on his or her mobile device so as to cause the mobile device to transmit a verification indication or a decline indication to the issuer FI. In some implementations, the process includes the cardholder providing an indication validating a purchase transaction and then being prompted to enter a secret mobile personal identification number (mPIN) that must be verified before a signal or message is sent to the issuer FI that indicates that the questionable purchase transaction is legitimate.
Furthermore, in some embodiments the mobile device application permits the cardholder to notify or warn the bank in advance that one or more “special” transactions will take place that should not be flagged as potentially fraudulent. This pre-authorization procedure may be conducted directly from the cardholder's mobile device and may be stored in a storage device associated with an electronic anti-fraud system of the issuer FI, for example.
The payment system 104 may operate in a conventional manner to route purchase transaction authorization requests from acquirers to issuers, and to route purchase transaction authorization responses back from the issuers to the acquirers. A separate system for clearing purchase transactions may also be provided by the operator of the payment system 104 which is not indicated in
Block 106 may be considered to represent the issuer financial institution (FI) and its computer and/or computer systems by which it participates in the payment card system. The issuer FI computer 106 may operate in a conventional manner to receive authorization requests via the payment system 104 and to transmit authorization responses back to the acquirer FI 102 via the payment system 104. In some implementations, the issuer FI 106 includes an electronic anti-fraud system 108, which may be an application program running on one or more server computers. The anti-fraud system 108 is operable to analyze purchase transaction data, cardholder data and/or other forms of data to determine and/or predict when a possibly fraudulent transaction is being attempted with regard to a consumers' financial account (for example, a purchase transaction may be considered to be dubious or possibly fraudulent if it includes a very expensive luxury item which does not match a spending profile of a particular cardholder who owns the financial account). In some embodiments, the issuing FI 106 is operably connected to an authorization server computer 110 which is operable to receive alerts (which will be explained below) from the electronic anti-fraud system 108 of the issuing FI 106. The authorization server computer 110 is also operable to communicate with a mobile device 112 (depicted in
Also shown in
The mobile telephone 200 may include a conventional housing (indicated by dashed line 202) that contains and/or supports the other components of the mobile telephone 200. The mobile telephone 200 further includes conventional control circuitry 204 for controlling over-all operation of the mobile telephone 200. In some implementations, the control circuitry 204 is suitably programmed to allow the mobile telephone 200 to engage in data communications and/or text messaging with other devices, and to allow for interaction with web pages accessed via browser software, which is not separately shown. Other components of the mobile telephone 200, which are in communication with and/or controlled by the control circuitry 204, include one or more memory devices 206 (for example, program and working memory, and the like); a conventional SIM (subscriber identification module) card 208; a conventional key pad 210 (or touch screen) for receiving user input; and a display 212 (which may again be a touch screen) for displaying output information to the user.
The mobile telephone 200 also includes conventional receive/transmit circuitry 216 that is also in communication with and/or controlled by the control circuitry 204. The receive/transmit circuitry 216 is coupled to an antenna 218 and provides the communication channel(s) by which the mobile telephone 200 communicates via a mobile network (not shown). The mobile telephone 200 further includes a conventional microphone 220, coupled to the receive/transmit circuitry 216. Of course, the microphone 220 is for receiving voice input from the user. A loudspeaker 222 is also included to provide sound or audio output to the user, and is coupled to the receive/transmit circuitry 216. In addition, a vibration system 224 is provided for use to alert the mobile telephone user of an incoming message.
The mobile telephone 204 may also include an integrated circuit (IC) or chipset 226 of the kind embedded in contactless payment cards. For example, an RFID IC 226 is connected to an antenna 228 and operates so as to interact with, for example, an RFID/NFC proximity reader of a POS terminal to provide a payment card account number and other information for a purchase transaction at the POS terminal. For example, the RFID chip 226 may be designed and/or programmed to operate in accordance with the well-known “PayPass” standard (promulgated by the assignee hereof) for contactless payment applications.
Referring again to
In addition, other applications 308 may be stored in the memory 206 of the payment-enabled mobile device 200 illustrated in
In some embodiments, a cardholder may be required to register to participate in an “Authorize My Transaction” system so that, for example, an alerting application may be downloaded to and stored in the memory of the cardholder's mobile device 112, such as a mobile telephone or other device as described above. The cardholder's issuing FI or a third party service provider (PSP) may be responsible for obtaining and storing information concerning the cardholder's mobile device, such as the type of mobile device and/or a mobile telephone number, and for providing the alerting application for loading onto the cardholder's mobile device. As mentioned above, the “Authorize My Transaction” application may include instructions that provide both post-authorization and pre-authorization functionality.
Referring again to
As mentioned above, a secret mark may also be displayed by the mobile device, which secret mark was selected previously by the consumer/cardholder at the time of registration for the “Authorize My Transaction” application. The secret mark may include, but is not limited to a word, a phrase, an alphanumeric code, a color(s), an icon, a picture or photograph, a drawing, a tactile indication, an audio tone(s), some other type of indicator or marking, and/or a combination of such representations and/or indications. Consequently, in some embodiments the secret mark is akin to a password in that it is only known by the issuing financial institution and the cardholder.
Accordingly, when the correct secret mark is displayed and/or presented by the mobile device, if the cardholder can verify that the secret mark is correct then he or she is confident that the transaction alert message originated from the issuer FI and thus that it is legitimate. So if the transaction alert information does not include a secret mark, or if the secret mark is incorrect, then the cardholder/mobile device user recognizes that the transaction alert message itself may be fraudulent. Fraudulent alert messages are commonly known as “phishing” attacks which are used by fraudsters in an attempt to have a cardholder provide sensitive financial account data via a fraudulent website or fraudulent menu that may be displayed on the mobile device. The fraudster then can use any such fraudulently obtained financial information to later commit fraud on that cardholder account. Thus, when the cardholder recognizes such a “phishing” attack, he or she must take care not to provide any information to the fraudster. Instead, the cardholder should contact the issuing FI to report the fraudulent “phishing” attempt and to seek guidance. However, under current practices, when an issuing FI contacts the cardholder, the cardholder generally does not have any convenient way to verify that the contact originated from the issuing FI. Due to the current level and frequency of “phishing” attacks, many cardholders now ignore unexpected communications from issuing financial institutions. Thus, the apparatus, systems and processes disclosed herein provide a means for cardholders to verify that the communication is genuine and originating from the issuing FI. Furthermore, the apparatus, systems and processes disclosed herein provide a communication channel between the cardholder and the issuing FI which is trusted by both parties.
In some embodiments, the secret mark may be stored in the secure element of the consumer's mobile device. For example, the secret mark may be downloaded during a registration process for the Authenticate My Transaction application and stored in the secure element of the mobile device. In this embodiment, when the secret mark is received by the mobile device from the authorization server computer along with the transaction alert information, the mobile device may operate to first ensure that the received secret mark matches the secret mark stored in the mobile device to confirm that the transaction alert message is a true and genuine message from the issuer. In an embodiment, such operation occurs without involving the cardholder, and occurs before providing the non-intrusive indication of a transaction alert message to the cardholder. For example, in some embodiments, the stored secret mark may be encrypted and thus must later be decrypted before a comparison can be made with a downloaded secret mark. Alternately or in addition, the received secret mark from the authorization server computer may be encrypted so that the mobile telephone must utilize one or more forms of cryptography in order to decrypt the received secret mark before making a comparison with the stored secret mark. In some implementations, issuer scripting in the form of post-issuance application management may be performed by the issuer FI, or other methods may be provided such that the mobile device operates to verify the authenticity of the secret mark before bringing the transaction alert message to the attention of the cardholder. In any or all of such implementations, since the mobile telephone operates to verify the received secret mark, the received secret mark may not be displayed or otherwise presented to the cardholder via the mobile device. Instead, the mobile device may display a “secret mark verified” message or the like so that the consumer or cardholder can be confident that the transaction alert message and the accompanying information that is displayed is genuine. Alternately, no such message may be displayed and the transaction alert information may just be displayed because in such cases it is understood by the cardholder (the mobile device owner) that such a secret mark verification process has already occurred in the background or else the transaction alert information would not be presented. But if the received secret mark does not match the secret mark stored in the secure memory, then in an implementation no transaction alert indication or any type of message may be displayed. Instead, in this case the mobile device may automatically log a fraudulent event and report the incident to the issuer FI without involving the cardholder. However, in some other embodiments a “Fraud Alert—Secret Mark Mismatch” message or the like could be displayed by the mobile device to inform the cardholder that a potential “phishing” message was received and that it was reported to the issuing FI.
Referring again to
Referring again to step 412, if the cardholder/mobile device user enters the correct mPIN, then the mobile device transmits 414 an authorization signal to the authorization server computer 110 (see
Referring again to
Returning now to step 408, if a validation indication is not received and then a transaction denied indication is not received in step 416, the process may idle 420 for a predetermined period of time before the process branches back to step 408 to again check if either such indication was received. If the predetermined idle period expires, then in some embodiments the process may time out and then a default mode of operation occurs. The default mode of operation may include the issuer FI blocking the potentially fraudulent transaction and/or suspending the cardholders' account. The issuing FI may then take subsequent action(s) to attempt to contact the cardholder, for example via e-mail and/or a telephone call to a home telephone number of the cardholder, so as to obtain further information regarding the potentially fraudulent transaction and/or to reinstate the cardholder's account.
In some embodiments the “Authorize My Transaction” application downloaded to the cardholder's mobile device may also be operable to permit the cardholder to provide advance warning (pre-authorization) to the issuing FI of a future or upcoming purchase that the cardholder believes might be flagged as a potentially fraudulent transaction. For example, if the cardholder is planning to or intends to buy an expensive leather sectional sofa for his home utilizing a particular payment card account, the cardholder can utilize the “Authorize My Transaction” application on his or her mobile device to enter information into a “pre-authorization” menu. The pre-authorization menu may include fields for providing, for example, the merchant's name, the merchant's retail store location or website address, the merchandise type (such as a make, model name, and/or a description and the like), the purchase price, and the future date of the purchase. The cardholder can then use his or her mobile device to transmit the pre-authorization information to the issuer FI via the authorization server for storage in a “pre-authorization” database such that it is associated with that cardholder's account. Thus, when the purchase transaction for the leather sofa occurs, the issuing FI checks the pre-authorization database for any pre-authorization information associated with that cardholder's account. In some embodiments, the issuing FI may ensure that a minimum threshold amount of the purchase transaction data matches the pre-authorization data provided by the cardholder from his or her mobile device. If so, then the issuing FI does not transmit a transaction alert message and instead continues with normal processing to either authorize the transaction or deny the transaction (for example, based on the creditworthiness of the cardholder). In some implementations, the issuing FI may also transmit an SMS message (or another type of message) to the cardholder's mobile device acknowledging the occurrence of the pre-authorized transaction.
After entry of the required purchase transaction data in fields 612-618, the cardholder enters the four-digit mPIN and the entries appear in entry fields 620 and, as explained above, the mPIN entries may be obscured for security reasons. After entry of the mPIN and pressing the “Submit” button 624, the mobile device compares the entered mPIN data to that stored in a secure area of the mobile device, and if a match occurs then the mobile device transmits the pre-authorization data to the authorization server. The process then proceeds as explained above with the pre-authorization information being forwarded to the issuer FI via the authorization server for storage in a “pre-authorization” database such that it is associated with that cardholder's account. When the purchase transaction then occurs with the designated merchant for the designated amount on the designated date, then the issuing FI will find that there is a match for the transaction in the pre-authorization database for the cardholder's account. The issuing FI then does not flag that transaction as being potentially fraudulent and does not transmit a transaction alert message. Instead, normal processing occurs to either authorize the transaction or deny the transaction (for example, based on the creditworthiness of the cardholder). In some implementations, the issuing FI may also transmit an SMS message (or another type of message) to the cardholder's mobile device acknowledging the occurrence of the pre-authorized transaction.
The computer processor 702 may constitute one or more conventional processors. Processor 702 operates to execute processor-executable steps, contained in program instructions described herein, so as to control the authorization server computer 700 to provide desired functionality.
Communication device 704 may be used to facilitate communication with, for example, other devices and/or server computers (such as for receiving data via the Internet or via a mobile network operator from a consumer mobile device and for transmitting data to the consumer mobile device). Communication device 704 may also, for example, have capabilities for engaging in data communications over conventional computer-to-computer data networks, in a wired or wireless manner. Such data communications may be in digital form and/or in analog form.
Input device 706 may comprise one or more of any type of peripheral device typically used to input data into a computer. For example, the input device 706 may include a keyboard and a mouse and/or a touchpad that may be used, for example, by a systems engineer or other personnel authorized to, for example, perform server computer system maintenance or other task. The output device 708 may comprise, for example, a display and/or a printer.
Storage device 710 may comprise any appropriate information storage device, including combinations of magnetic storage devices (e.g., magnetic tape and hard disk drives), optical storage devices such as CDs and/or DVDs, and/or semiconductor memory devices such as Random Access Memory (RAM) devices and Read Only Memory (ROM) devices, as well as flash memory devices. Any one or more of the listed storage devices may be referred to as a “computer readable medium”, “memory”, “storage” or a “storage medium”.
Storage device 710 stores one or more programs for controlling processor 702. The programs comprise program instructions that contain processor-executable process steps of the authorization server computer 700, including, in some cases, process steps that constitute processes provided in accordance with principles of the processes presented herein.
The programs may include a cardholder registration application 712 that manages a process wherein consumers register themselves and their consumer mobile device(s) for the “Authorize My Transaction” services which may include the post-transaction process and the pre-authorization process, as described herein. In some embodiments, the cardholder registration application may allow consumers to register one or more payment accounts with the authorization server by accessing, for example via their mobile telephone or tablet computer or laptop computer, a suitable web page hosted by the authorization server computer. The information obtained from the consumer during the registration process may include the consumer's name, residence address, email address, one or more primary payment account numbers (PANs), a mobile telephone number (or other mobile identifier), an e-mail address, and consumer mobile device information. In some embodiments, the application programs may also include an issuer FI registration application 714 that manages a process by which issuing FI's register with the authorization server in order to offer the “Authorize My Transaction” service to consumers/cardholders. In some implementations, issuing FI's register by accessing an issuer FI registration web page from an authorization server computer website that includes an issuing FI interface for providing required information.
The storage device 710 may also include a “Pre-Authorization” database 716 for storing pre-authorization transaction data provided by cardholders and for use by issuer FI's, as explained above. In addition, one or more other databases 718 may be maintained by the authorization server computer 700 on the storage device 710. Among these databases may be, for example, a cardholder registration information database, an issuer FI registration information database, and the like.
The application programs of the wallet server computer 700, as described above, may be combined in some embodiments, as convenient, into one, two or more application programs. Moreover, the storage device 710 may store other programs or applications, such as one or more operating systems, device drivers, database management software, web hosting software, business intelligence software (for example, to determine analytics which may be useful to merchants), and the like.
As the term “payment transaction” is used herein and in the appended claims, it should be understood to include the types of transactions commonly referred to as “purchase transactions” that may involve payment card accounts and/or payment card systems. The purchase transactions may be in connection with traditional point-of-sale (POS) transactions that may occur in a merchant's retail locations, or may be eCommerce transactions that occur through use of the internet.
The term “storage device” as used herein and in the appended claims may include any appropriate information storage device, including combinations of magnetic storage devices (e.g., magnetic tape and hard disk drives), optical storage devices such as CDs and/or DVDs, and/or semiconductor memory devices such as Random Access Memory (RAM) devices and Read Only Memory (ROM) devices, as well as flash memory devices. Any one or more of the listed storage devices may be referred to as a “computer readable medium”, “memory”, “storage” or a “storage medium”. In addition, it should be understood that the term non-transitory computer-readable media or non-transitory computer readable medium includes all computer-readable media, with the sole exception being a transitory, propagating signal.
The above descriptions and illustrations of processes herein should not be considered to imply a fixed order for performing the process steps. Rather, the process steps may be performed in any order that is practicable, including simultaneous performance of at least some steps.
Although the present invention has been described in connection with specific exemplary embodiments, it should be understood that various changes, substitutions, and alterations apparent to those skilled in the art can be made to the disclosed embodiments without departing from the spirit and scope of the invention as set forth in the appended claims.
