U.S. patent application number 14/669304 was filed with the patent office on 2015-07-30 for credit card fraud prevention system and method.
The applicant listed for this patent is Deloitte Development LLC. Invention is credited to Joseph Lee Johnson, JR., Jared Scott Miniman, Prakash Santhana, Rangaswami Saravanan.
Application Number | 20150213451 14/669304 |
Document ID | / |
Family ID | 53038298 |
Filed Date | 2015-07-30 |
United States Patent
Application |
20150213451 |
Kind Code |
A1 |
Santhana; Prakash ; et
al. |
July 30, 2015 |
CREDIT CARD FRAUD PREVENTION SYSTEM AND METHOD
Abstract
A mobile computing device is adapted to transmit to a scoring
server URLs of websites browsed using the device. The scoring
server can compare these URLs against a merchant URL obtained
within a preselected time period from transaction data resulting
from a transaction involving a payment product of the device user.
A score can be calculated based on the similarity between each URL
obtained from the device and the URL from the transaction data. The
score represents the likelihood that a website browsed using the
device and, as a result, the transaction, is fraudulent. The
browsed URLs can also be scored against a database of known
fraudulent websites. A notification concerning the legitimacy of
the transaction based on the score can be generated and sent to the
mobile device in real-time. On receiving the notification, the
device can be used to either accept or decline the transaction in
real-time.
Inventors: |
Santhana; Prakash; (Amawalk,
NY) ; Miniman; Jared Scott; (Washington, DC) ;
Johnson, JR.; Joseph Lee; (Brandon, MS) ; Saravanan;
Rangaswami; (Kellyville, AU) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Deloitte Development LLC |
Hermitage |
TN |
US |
|
|
Family ID: |
53038298 |
Appl. No.: |
14/669304 |
Filed: |
March 26, 2015 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
13906870 |
May 31, 2013 |
9031877 |
|
|
14669304 |
|
|
|
|
61653836 |
May 31, 2012 |
|
|
|
61711351 |
Oct 9, 2012 |
|
|
|
61776346 |
Mar 11, 2013 |
|
|
|
Current U.S.
Class: |
705/44 |
Current CPC
Class: |
G06Q 20/4014 20130101;
G06Q 20/4016 20130101; G06Q 20/4014 20130101; G06Q 20/401 20130101;
G06Q 20/322 20130101 |
International
Class: |
G06Q 20/40 20060101
G06Q020/40 |
Claims
1. A payment product fraud prevention method, comprising:
automatically receiving by at least one computing device platform
server first identifiers representing uniform resource locators
associated with websites browsed using computing devices recognized
by the at least one computing device platform server as being
registered to a user, each of the first identifiers having been
automatically obtained and transmitted from the registered
computing devices during browsing; receiving by the at least one
computing device platform server a second identifier from
transaction authorization data resulting from a transaction
involving a payment product associated with the user; using the at
least one computing device platform server to: compare the second
identifier against ones of the first identifiers obtained within a
preselected time period prior to the transaction, and calculate at
least one score based on a degree of similarity between the second
identifier and one or more of the ones of the first identifiers
obtained within the preselected time period prior to the
transaction, the at least one score representing a likelihood that
the transaction is fraudulent; and causing a notification to be
transmitted to the registered computing devices in substantially
real time, the notification indicating the likelihood that the
transaction is fraudulent.
2. The method of claim 1, further comprising causing the
transaction to be one of blocked and accepted based at least in
part on the at least one score.
3. The method of claim 1, further comprising storing the first
identifiers and the at least one score such that the first
identifiers and the at least one score are available for data
mining.
4. The method of claim 1, wherein the notification includes a
threat level indicating a severity of the transaction.
5. The method of claim 4, wherein the threat level is one of low,
moderate and high.
6. The method of claim 1, further comprising prompting the user to
one of confirm and deny the transaction.
7. The method of claim 1, wherein the notification includes at
least one additional message.
8. The method of claim 7, wherein the at least one additional
message includes a deposit account alert indicating that a check
drawn on a financial account of the user has exceeded a preselected
threshold amount.
9. The method of claim 8, further comprising prompting the user (i)
to one of approve and decline the check, and (ii) when the check is
declined, to submit a fraud claim.
10. The method of claim 7, wherein the at least one additional
message includes at least one of an advertising, a marketing, and a
promotional offer message.
11. The method of claim 1, wherein the first identifiers include a
first merchant name, and wherein the second identifier is a second
merchant name one of (i) from the transaction authorization data,
and (ii) obtainable based on the transaction authorization data
from a source other than the transaction authorization data.
12. The method of claim 11, wherein the source other than the
transaction authorization data is at least one database of merchant
names and their associated doing-business-as names.
13. The method of claim 1, wherein the second identifier is a
merchant uniform resource locator one of (i) from the transaction
authorization data, and (ii) obtainable based on the transaction
authorization data from a source other than the transaction
authorization data.
14. The method of claim 13, wherein the source other than the
transaction authorization data is at least one database of merchant
names and their associated doing-business-as names and their
associated uniform resource locators.
15. The method of claim 13, wherein comparing the second identifier
against the ones of the first identifiers obtained within a
preselected time period prior to the transaction includes
identifying a first, a second and a third uniform resource locator
character substring in each of such first and second identifiers,
and determining the number of characters that match by position
between the (i) first substring of each of such first and second
identifiers; (ii) second substring of each of such first and second
identifiers, and (iii) third substring of each of such first and
second identifiers.
16. The method of claim 15, wherein calculating the at least one
score based on the degree of similarity between the second
identifier and the one or more of the ones of the first identifiers
obtained within a preselected time period prior to the transaction
includes dividing the number of characters that match by position
between the second substring of each of such first and second
identifiers by the greater of the number of characters in (i) the
second substring of such first identifiers or (ii) the second
substring of the second identifier.
17. The method of claim 15, wherein calculating the at least one
score based on the degree of similarity between the second
identifier and the one or more of the ones of the first identifiers
obtained within a preselected time period prior to the transaction
includes adding together the number of characters that match by
position between the first substring of each of such first and
second identifiers and the third substring of each of such first
and second identifiers to yield a sum, and dividing the sum by the
greater of the number of characters in (i) both the first and
second substrings combined of such first identifiers or (ii) both
the first and second substrings combined of the second
identifier.
18. The method of claim 1, further comprising comparing the ones of
the first identifiers obtained within a preselected time period
prior to the transaction against uniform resource locators of known
fraudulent websites to determine whether such first identifiers
correspond to any of the fraudulent websites.
19. The method of claim 1, wherein the payment product is one of a
credit card, a charge card, and a debit card.
20. The method of claim 1, wherein the computing devices include at
least one of a smartphone, a tablet computer, a laptop computer, a
notebook computer, and a personal digital assistant.
21. The method of claim 1, further comprising receiving time stamp
information indicating when each of the first identifiers were
extracted and transmitted from the registered computing devices
during browsing; and storing the time stamp information together
with the first identifiers.
22. The method of claim 1, wherein receiving the first identifiers
is effected only when a website checkout page is browsed using the
registered computing devices.
23. The method of claim 1, further comprising updating a database
identifying fraudulent websites based at least in part on the at
least one score.
24. A computer program product comprising a non-transitory medium
storing computer executable program logic to: cause a mobile
computing device registered to a user to automatically transmit at
least one first identifier to a scoring server, the at least one
first identifier representative of at least one uniform resource
locator associated with at least one website browsed using the
mobile computing device; cause the mobile computing device to
receive a notification concerning the legitimacy of a transaction
involving a payment product associated with the user, the
notification being based on a score calculated by at least one data
processing device associated with the scoring server, the score
being based on a degree of similarity between a second identifier
obtained from data concerning the transaction and one or more of
the at least one first identifier obtained within a preselected
time period prior to the transaction; and enable the user to one of
accept and decline the transaction in real-time using the mobile
computing device.
25. The computer program product of claim 24, wherein causing the
mobile computing device to automatically transmit the at least one
first identifier to the scoring server is effected only when a
checkout page of the at least one website is browsed using the
mobile computing device.
26. The computer program product of claim 24, wherein the
notification includes a threat level indicating a severity of the
transaction.
27. A payment product fraud prevention system, comprising: a mobile
computing device registered to a user and adapted to scrape at
least one first identifier representative of a uniform resource
locator associated with at least one website browsed using the
mobile computing device; a scoring server, the scoring server being
configured to receive (a) the at least one first identifier from
the mobile computing device, and (b) a second identifier from
transaction authorization data concerning a transaction involving a
payment product associated with the user; and at least one data
processing device associated with the scoring server, the at least
one data processing device being adapted to (i) compare the second
identifier against one or more of the at least one first identifier
obtained within a preselected time period prior to the transaction,
and (ii) calculate at least one score based on a degree of
similarity between the second identifier and the one or more of the
at least one first identifier, the at least one score representing
a likelihood that the transaction is fraudulent; wherein the mobile
computing device is further adapted to receive a notification sent
one of directly and indirectly from the scoring server indicating
the likelihood that the transaction is fraudulent.
28. The system of claim 27, further comprising at least one
database storing uniform resource locators of fraudulent websites;
and wherein the scoring server is configured to compare the at
least one first identifier against the at least one database to
determine whether the at least one first identifier corresponds to
any of the fraudulent websites.
29. The system of claim 27, wherein the mobile computing device is
adapted to enable the user to one of accept and decline the
transaction in real-time.
30. The system of claim 27, wherein the mobile computing device is
adapted to obtain the first identifier only when a checkout page of
the website is browsed using the mobile computing device.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation of U.S. application Ser.
No. 13/906,870 filed May 31, 2013 which claims the benefit of U.S.
Provisional Patent Application Nos. 61/653,836 filed on May 31,
2012, 61/711,351 filed on Oct. 9, 2012, and 61/776,346 filed on
Mar. 11, 2013, the disclosures of which are hereby incorporated
herein by reference in their entireties.
COPYRIGHT NOTICE
[0002] Portions of the disclosure of this patent document contain
materials that are subject to copyright protection. The copyright
owner has no objection to the facsimile reproduction of the patent
document or patent disclosure as it appears in the U.S. Patent and
Trademark Office patent files or records solely for use in
connection with consideration of the prosecution of this patent
application, but otherwise reserves all copyright rights
whatsoever.
FIELD OF THE INVENTION
[0003] The present invention relates generally to the area of
electronic commerce security, and more particularly to protecting
against fraud in online payment product transactions involving a
mobile computing device.
BACKGROUND OF THE INVENTION
[0004] Today's mobile computing devices typically run complete
operating system software providing a standardized interface and
platform for application (or "app") developers. Simply put, an app
is software for enhancing a user's experience on a mobile computing
device. In recent years there has been tremendous growth in demand
for mobile computing devices boasting powerful processors, abundant
memory, large screens and open operating systems. A smartphone is
one example of a popular mobile computing device that includes a
phone with e-mail and Internet access features. Demand for apps has
grown in step.
[0005] Banks, financial institutions and other issuers of credit
cards, bank cards, charge cards, and other payment products, as
well as other e-businesses, have focused great attention on tapping
into the rising demand for mobile computing devices through the
provision of online, mobile financial services and transaction
capabilities. However, they have faced hurdles in this regard,
including the increasing problem of online/mobile fraud.
[0006] Online/mobile credit card fraud is a growing menace to card
issuers, e-businesses and their customers as fraudsters target
online payments using stolen card details. This type of
"card-not-present" fraud takes advantage of the inability of
merchants who sell and ship products and provide services online to
physically inspect the credit cards. So, when credit card details
(which can be easily stolen) are provided over the Internet, it is
difficult for a merchant to verify that it is, in fact, the true
card holder who is authorizing the purchase. Compounding the
problem, shipping companies eschew taking responsibility for
checking identification at the addresses where they ship
products.
[0007] Credit card fraud is also an adjunct to identity theft.
Phishing is one particularly problematic technique used to gain
personal information for purposes of identity theft. Fraudsters use
authentic-looking, fraudulent e-mail messages (which can include
links to fraudulent websites) that appear to come from legitimate
sources to fool recipients into divulging personal data such as,
for example, card numbers, bank account numbers and passwords. It
has been reported that approximately 450,000 phishing attacks in
2012 led to losses of approximately $1.5 billion--an increase of
about 59% in number and 22% in financial loss over the previous
year.
[0008] The financial services industry has developed preventive
measures. But, such measures have met with limited success, i.e.,
because of vulnerability to fraud (such as, for example,
"man-in-the-middle attacks" where a fraudster intercepts all
messages between two endpoints, making each endpoint believe that
it is communicating directly with the other over a private
connection, when, in fact, the entire conversation is controlled by
the fraudster) and/or poor industry adoption (e.g., because the
measure is intrusive to the card holder at the point of sale). EMV
(EUROPAY, MASTERCARD and VISA) smart card "chip and PIN" technology
(the "chip" denoting the integrated circuit embedded in the card;
the "PIN" denoting the personal identification number that must be
supplied by the card holder) is one example. However, a drawback of
using EMV cards is that, in card-not-present transactions, the card
holder must use a personal card reading device.
[0009] Single and multi-factor authentication approaches also have
their drawbacks in the online banking arena. Such approaches
require the presentation of one or of two or more of three
authentication factors: a knowledge factor ("something the user
knows"), a possession factor ("something the user has"), and an
inherence factor ("something the user is"). The single factor
approach (e.g., a password) has been shown to be highly vulnerable
to phishing attacks; the two-factor approach (e.g., a password and
a secure token or a fingerprint) has been shown to be vulnerable to
man-in-the-middle attacks; and the three-factor approach (e.g., a
password, a secure token and a fingerprint) has experienced poor
adoption by customers by reason of being too complicated.
[0010] Additionally, the use of credit card verification codes
(e.g., CVC2/CVV2) in the e-commerce arena has proved vulnerable to
phishing attacks. These are the three- or four-digit codes printed
on the front of the card or on the signature strip on the back.
SUMMARY OF THE INVENTION
[0011] Generally speaking, the present invention relates to a new
system and method that leverages a mobile computing device
platform, such as for example a smartphone platform, to enable
issuers of credit cards and other payment products to protect their
card holders against online/mobile fraud while conducting financial
transactions, and to communicate in real-time with the card holders
concerning not only threat levels and attempted fraud, but also
legitimate promotional offers and other messages.
[0012] According to one, preferred embodiment of the present
invention, an inventive app resident on a user's mobile computing
device can automatically cause the device to track, scrape and
transmit to a scoring server, all URLs of websites browsed by the
user. The scoring server can compare these URLs against a merchant
URL obtained within a preselected time period from the transaction
authorization data generated as a result of a transaction involving
a payment product (e.g., credit card, charge card, debit card, or
the like) of the user. A score can then be calculated based on the
degree of similarity between each URL obtained from the user's
device and the URL obtained from the transaction data (e.g., using
text matching). The score represents the likelihood that a website
browsed by the user and, as a result, the transaction, is
fraudulent. That is, a score indicating a low degree of similarity
raises the specter that a card-not-present transaction occurred
with a merchant whose website the user did not actually
visit--either because the user intended to transact with the
legitimate merchant online but was, unbeknownst to the user, lured
to a fraudulent site, or because the user did not even attempt to
browse the merchant's site.
[0013] Based on the score, the bank or other financial institution
responsible for processing the transaction can block or accept it.
A notification concerning the legitimacy of the transaction based
on the score can be generated and sent to the user's mobile device
in real-time. On receiving the notification, the user can authorize
the bank or other financial institution to either accept or decline
the transaction. This can be accomplished in real-time using the
mobile device.
[0014] According to a further embodiment of the present invention,
the URLs visited by the card holder can also be scored against a
database of known fraudulent websites.
[0015] According to a still further embodiment of the present
invention, the database of known fraudulent websites can be updated
based on the results of the scoring process.
[0016] According to another embodiment of the present invention,
notifications to the user can include additional messages, such as,
for example, a deposit account alert indicating that a check drawn
on the user's account may be fraudulent. Informational and
advertising/promotional messages can also be delivered to the user
via the notifications.
[0017] According to yet another embodiment, the URLs and the scores
can be stored and made available for data mining purposes.
[0018] Still other aspects and advantages of the present invention
will in part be obvious and will in part be apparent from the
specification.
[0019] The present invention accordingly comprises the several
steps and the relation of one or more of such steps with respect to
each of the others, and embodies features of construction,
combinations of elements, and arrangement of parts adapted to
effect such steps, all as exemplified in the detailed disclosure
hereinafter set forth, and the scope of the invention will be
indicated in the claims.
BRIEF DESCRIPTION OF THE DRAWINGS
[0020] For a fuller understanding of the invention, reference is
made to the following description, taken in connection with the
accompanying drawings, in which:
[0021] FIG. 1 is a schematic diagram depicting an exemplary credit
card fraud prevention system according to an embodiment of the
present invention;
[0022] FIG. 2 is a flow chart illustrating an exemplary mobile
device registration process according to an embodiment of the
present invention;
[0023] FIG. 3 is a flow chart illustrating an exemplary server-side
user registration process according to an embodiment of the present
invention;
[0024] FIG. 4 is a flow chart illustrating an exemplary process for
protecting against credit card fraud in accordance with an
embodiment of the present invention;
[0025] FIGS. 5A-5C depict exemplary threat level notifications
according to an embodiment of the present invention; and
[0026] FIGS. 6A-6C illustrate an exemplary two-way messaging
process according to an embodiment of the present invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0027] FIG. 1 illustrates an exemplary architecture of a credit
card fraud prevention system 100 according to an embodiment of the
present invention. In some cases, the functional components of the
system may be hardware, software or combinations of hardware and
software.
[0028] On the card holder side, the system 100 includes the card
holder's mobile computing device 110 (e.g., smartphone, tablet,
laptop computer, etc.), which can have a web browser or the like
installed thereon. The mobile computing device 110 can also have an
app installed thereon that supplants or works in conjunction with
the web browser (that is, a software component, e.g., an add-on or
plug-in, that enhances the web browser) to provide functionality as
described in greater detail hereinafter.
[0029] As is known in the art, a web browser (e.g., GOOGLE CHROME,
FIREFOX, INTERNET EXPLORER, OPERA and SAFARI) is a software
application that enables users to access, retrieve and view
documents and other information resources on the Internet. To
access a resource on the Internet, the user inputs a Uniform
Resource Locator ("URL"), or web address, into the browser. The
ubiquitous "http://" URL prefix identifies a resource to be
retrieved via the HyperText Transfer Protocol (HTTP).
[0030] On the merchant side, there can be a merchant web server
120. Such web server is either the hardware or the software that is
used to deliver content that can be accessed through the Internet
and to receive and process purchase requests made by the card
holder via the mobile computing device 110.
[0031] Typically, in processing a credit card purchase, the
merchant transmits data about the purchase to the bank or other
financial institution 140 that issued the card, e.g., directly if a
credit card association, such as for example MASTERCARD or VISA, is
not implicated, or, if a credit card association is implicated, by
way of the merchant's processing bank, which transmits the
transaction data to the credit card association, which then
transfers the data to the issuing bank or financial institution 140
(it should be appreciated that the present invention is not limited
to use of a credit card association model; the present invention
has application with respect to payment products issued without the
involvement of a credit card association). The issuing bank or
other financial institution 140 then pays the merchant the amount
on the credit card receipt (minus any transaction fee or
commission), typically by applying a credit to the merchant's
account (e.g., at the processing bank). The credit card issuer then
applies the amount of the purchase to the card holder's balance on
the credit card. The credit card network transaction authorization
server 130 shown in FIG. 1 represents a mechanism by which a credit
card purchase transaction can be processed according to
conventional practices.
[0032] A scoring data server 150 can be provided on the financial
transaction processing side (e.g., associated with or otherwise
serving the bank or other financial institution that issued the
card); and a central server 160 (e.g., also associated with or
otherwise serving the issuing bank or other financial institution)
can be functionally interposed between the card holder and the
scoring data server. These servers 150, 160 can be configured to
carry out functions in accordance with the embodiments of the
present invention described in greater detail hereinafter.
[0033] A fraud prevention process according to an embodiment of the
present invention, which can leverage the system 100 illustrated in
FIG. 1, can involve registering the card holder's mobile device(s)
110. Referring also to FIG. 2, to register a device 110, the card
holder can install the app, which includes a programmed set of
instructions that can be executed on the device to effect the
inventive processes, e.g., by downloading the app from the Internet
(step 210) using, for example, conventional communication links.
Thereafter, the card holder can enroll as a user of the fraud
prevention system 100 and process (step 220) through the card
holder's mobile device 110.
[0034] Referring to FIG. 3, enrolling as a user (including creating
a user account) can involve sending user information to the central
server 160 (step 310), which can be the issuing bank's server or
managed by a registration service that is either affiliated with or
independent of the bank or other financial institution that issued
the card. This user information can include the card holder's name
(as presented on the card), addresses (billing, home, work),
telephone numbers (mobile device number, home number, work number),
e-mail addresses, and card information, i.e., the card type (e.g.,
debit, credit or charge; MASTERCARD, VISA or AMEX), the card
number, CVV/CVC and expiration date. Additionally, the enrollment
process may involve suitable conventional security measures such
as, for example, providing answers to preselected security
questions--indeed, it should be generally understood that issuing
banks and other financial institutions can continue to employ all
conventional security measures to protect customer transactions in
tandem with any and all aspects of the salutary fraud prevention
functionality provided by the embodiments of the present
invention.
[0035] Thereafter, the central server 160 can process an
authorization request to the bank or other financial institution
140 that issued the card (step 320). Such request can include at
least a subset of the information provided to the central server
160 by the card holder in step 310. Preferably, such request
includes the card information and billing ZIP code. The
authorization request information can then be validated by the card
issuer (step 330).
[0036] If an approval code is received with a valid match on all
parameters at step 330, a unique ID can be generated for the mobile
device 110 using the information provided with the authorization
request (step 340); and the information including the unique ID can
be stored in a secure database 170, which can be accessible by both
the central server 160 and the scoring data server 150 (step 345).
A hashed version of the unique ID can then be delivered to the
device 110 (step 360). As an optional added security measure, when
the unique ID has been generated and the hashed version delivered
to the mobile device, all credit card information can be erased
from the mobile device and the central server 160--leaving the
scoring server 150 as the only place where the link between the
unique ID and the card holder's credit card number exists.
[0037] If the authorization request cannot be validated at step
330, a message to this effect can be delivered to the card holder,
and the user enrollment process can be revisited (see FIG. 2, step
350) or terminated.
[0038] Referring back to FIG. 2, with a successful user enrollment
at step 230, the device registration process can continue at step
240, where the hashed version of the unique ID can be stored in the
mobile device 110. Thereafter, the card holder can login to the
fraud prevention system 100 for the first time (step 250), and with
a successful login at step 260, take advantage of the features of
the system 100 as described below (step 270). In the event of an
unsuccessful user enrollment at step 230, or in the event of an
unsuccessful first login at step 260, the card holder can revisit
the user enrollment process at step 220.
[0039] It should be understood that, if the card holder has already
registered the card holder's mobile device 110, for example, in
connection with enrollment in an online banking relationship, the
registration/enrollment process for purposes of the present
invention can be streamlined. That is, it may only involve
downloading the inventive app, as all the requisite card and device
information should have already been provided.
[0040] Referring now to FIG. 4, to use the fraud prevention system
100 illustrated in FIG. 1, the enrolled card holder simply logs in
using the registered mobile device 110 to navigate online and
engage in web browsing/online shopping activity (steps 402 and
404). Preferably, the card holder can be prompted to enter a
password or answer one or more security questions to access the
functionality of the inventive app (desirably, the card holder need
not show any other credential for any card or bank transaction
conducted while using the app). This protects the card holder in
the event that the card holder's mobile device 110 is lost or
stolen.
[0041] During web browsing/online shopping activity, the app
resident on the mobile device 110 can track the websites visited by
the card holder and can scrape and "push" the URLs to the scoring
server 150 (steps 406 and 408). As an alternative to pushing URLs
for all websites visited, the app can scrape and push the URLs only
when a "checkout" page is encountered.
[0042] Preferably, the data can be sent to the scoring server 150
along with time stamp information. The scoring server 150 can store
the time-stamped data for the registered card holder for a
preselected period of time.
[0043] When a transaction occurs (step 410), a merchant
identification (e.g., typically including the merchant's name and
URL) is sent in the authorization data stream from the merchant's
point-of-sale system 120 (FIG. 1) to the credit card network
transaction authorization server 130 in accordance with
conventional practices. This identification can then be passed
(e.g., directly or via the central server 160) to the scoring
server 150 (step 412).
[0044] At the scoring server 150, the merchant identification in
the authorization data stream can be compared against the URLs
visited by the card holder using the registered mobile device 110
within a preselected time frame to determine whether the
transaction is legitimate (step 414) (e.g., did a card-not-present
transaction occur with a merchant whose website the card holder did
not visit using any of the card holder's registered mobile
devices--either because the card holder intended to transact with
the merchant online but was instead lured to a phishing site, or
the card holder just did not attempt to visit the merchant's
website?). That is, for example, a transactional scoring algorithm
can use text matching to compute scores based on the characters
that match between portions of the merchant URL in the
authorization data and the pushed URLs. Scores can be based on the
degree of a match or the number of characters that match in the URL
strings from the two data streams (matching character against
character strictly by their positions in the strings) divided by
the length of the longest string (preferably, excluding "."s).
Scores can be scaled as desired to range from 0 to 1000, for
example, with 1000 indicating a perfect match, and 0 indicating no
match (e.g., a score of 0 can be returned if the user did not
browse any websites using a registered mobile device to compare
against a transaction in the relevant time period).
[0045] The score ranges can define the fraud threat levels. For
example, a score falling in the range of 0-400 can indicate a high
threat level, a score of 401-700 can indicate a moderate threat
level, and a score of 701-1000 can indicate a low threat level.
[0046] More particularly, each URL can be broken into three
substrings (str1, str2 and str3), which reside between the
"http://" or "https://" and the next "/": str1="www"; str2=the
merchant name; and str3=the domain (e.g., `com`, `net`, etc.). If
the merchant name score is above 700 and the concatenated str1+str3
score is 1000, then the threat level is low. If the merchant name
score falls within the range 400-700 and the concatenated str1+str3
score is 1000, the threat level is moderate. If the merchant name
score is below 400 or if the concatenated str1+str3 score is not
1000, the threat level is high.
[0047] Note that if the pushed URL is a phishing site, the merchant
name score can be expected to be moderate to high, but the URL
score (str1+str3) will not be 1000. For example, "www.amazoncom.ru"
(as opposed to "www.amazon.com") scores high for the merchant name
(str1) match (6/9.times.1000=about 667), but the URL score does not
equal 1000 (3/6.times.1000=500). Thus, because the URL score is not
1000, the threat level is high.
[0048] As another example, which illustrates that characters are
compared based on their positions in the strings, take
"www.amzon.com": the URL score is 1000 (6/6.times.1000); but, the
merchant name score is about 333 (2/6.times.1000), which indicates
a high threat.
[0049] Additionally or alternatively, one or more databases (e.g.,
database 180) accessible by the scoring server 150 can store
correlations between merchants and their URLs (e.g., in a lookup
table) that can be leveraged by the scoring algorithm in comparing
the merchant identification in the authorization data stream
against the merchant URL visited by the card holder to determine
transaction legitimacy. This is advantageous where, for example,
the merchant's URL is not included in the card authorization data
and the merchant uses a URL that contains a different name (e.g.,
where the merchant uses a doing-business-as or "DBA" name) such
that scoring based on text matching of merchant names may yield
inconclusive results.
[0050] Also, when DBA names of merchants are different from their
URLs, customers may not recognize transactions reported on their
credit card statements, which can lead to unnecessary chargebacks.
It should be appreciated that the capability of the inventive
embodiments described below to alert the customer to the difference
at the time of the transaction can help to avoid such unnecessary
chargebacks. The card issuer can accumulate responses from the
customer (e.g., via two-way messaging) concerning such
transactions--storing the names of all merchants with DBA names
different from their URLs with whom the customer transacted. This
database (e.g., database 180) can be used on the backend when
chargebacks are initiated.
[0051] Further, at the scoring server 150, the merchant URLs
visited by the card holder can be compared against a database
(e.g., database 180) of known phishing or other problematic
websites (step 418). A score can be computed based thereon. So, if
the resulting score is high, then the site visited is probably a
fraudulent site.
[0052] Based on all the scoring discussed above, the transaction
can then be either blocked or approved by the bank or other
financial institution that issued the card, and a push notification
to that effect can be sent in real time to the card holder's mobile
device 110 (steps 420 or 422), e.g., directly from the scoring
server 150 or via the central server 160. The card holder can then
instruct the issuing bank or other financial institution (e.g., in
real-time via two-way messaging) as to whether the transaction
should or should not be consummated.
[0053] The notification to the card holder can be in the form of
different threat levels to indicate the severity of the transaction
or the website. For example, referring to FIGS. 5A-5C, three
categories of threat level notifications can be generated based on
the scoring: a low threat level illustrated in FIG. 5A (or safe or
known website); a moderate threat level illustrated in FIG. 5B (or
questionable or possible malicious website); and a high threat
level illustrated in FIG. 5C (or dangerous or known malicious
website). It should be understood that moderate and high threat
levels preferably result in the issuing bank or other financial
institution automatically blocking the transaction.
[0054] The notifications pushed to the card holder's mobile device
110 can also be color-coded based on the different threat levels.
For example, the color green can be used to denote a low threat
level; yellow to denote a moderate threat level; and red to denote
a high threat level.
[0055] In view of the foregoing, a scoring algorithm can execute in
accordance with the following exemplary logic:
[0056] Inputs: merchant name and card number.
[0057] i. Get all the captured URLs and the corresponding log IDs
in the past T seconds.
[0058] ii. For each of the URL and log ID, call the match
algorithm. [0059] Match algorithm: [0060] 1. If the URL has more or
fewer than 3 substrings, a score is not calculated and the
following steps are skipped. [0061] 2. If the URL has 3
substrings--from the URL, getting str1 (protocol name), str2
(merchant name) and str3 (domain name). [0062] 3. Calling the
string match algorithm with the merchant names from the phishing
list and the merchant name (str2). The string match algorithm
returns the list of matched merchant names along with the scores.
[0063] 4. Calling the string match algorithm with the captured URL
from the phishing list and the URL (str1+str3). The string match
algorithm returns the list of matched URLs along with the scores.
[0064] If the merchant result set returned from string matching is
empty, update the visit log for this merchant with site name=`NA`,
merchant score=0, URL score=0. [0065] If the merchant result set
returned from string matching is not empty: [0066] Get the merchant
score using the log ID from the visit log. If the merchant score is
already present, the following steps are skipped. [0067] If the
merchant score is not present, get the site ID from the phishing
list based on the merchant score or captured URL. [0068] Update the
visit log for the selected merchant name with site name=`merchant
name with the highest score from the merchant result set obtained
from string matching`, merchant score=`highest score from the
merchant result set obtained from string matching`, URL
score=`highest score from the URL result set obtained from string
matching` (if no URL match found, update as 0).
[0069] iii. Get the latest merchant name, captured URL, captured
time stamp, merchant score, URL score etc. from the visit log
visited by the owner of the card selected in the past T seconds and
captured URL like selected.
[0070] iv. If no record is returned, it means the selected merchant
is not visited. (Merchant score=0, URL score=0, Title=Fraudulent
Transaction Performed, color code=red, description=The requested
merchant was not visited from registered device(s). Your
transaction may not be Legitimate. Please call 888-888-8888
immediately.).
[0071] v. If a record is returned:
[0072] If the site name is `NA`, color code=B, title=Not Available,
description=YOUR BANK has no adverse records for the site. No
action is required.
[0073] If the flag is `P`, color code=1.
[0074] If the captured URL has more or fewer than 3 substrings,
color code=2.
[0075] If the merchant name score is above 700 and str1+str3 score
is 1000, color code=4.
[0076] If the merchant name score is between 400 and 700 and
str1+str3 score is 1000, color code=3.
[0077] If the merchant name score is below 400 or if str1+str3 is
not 1000, color code=2.
[0078] Output:
[0079] 1 Malicious Site warning. YOUR BANK has identified this site
as a possible malicious site. Please call 888-888-8888 immediately.
Red.
[0080] 2 Unknown Site, potentially malicious. YOUR BANK does not
recognize this site. Your transaction may not be approved. Please
call 888-888-8888 immediately. Red.
[0081] 3 Unrecognized Site. YOUR BANK does not recognize this site.
You are advised to call 888-888-8888 as a precaution. Yellow.
[0082] 4 Site Recognized. YOUR BANK recognizes this site. No action
is required. Green.
[0083] Table 1 below includes additional scoring examples (based on
the foregoing and on the assumption that the legitimate website is
"http://www.chase.com").
TABLE-US-00001 TABLE 1 URL Merchant Score URL Score Threat
http://wwwchase.com/ 0 0 High http://www-chase.com/ 0 0 High
http://www.chasecom.com/ 625 1000 Moderate http://chase.com.cc/ 200
143 High http://www.chase.com- 1000 0 High sweepstakes-2011a.info/
http://www.chase.com 1000 1000 Low
[0084] The notifications pushed to the customer's mobile device can
advantageously include additional real-time messages from the bank
or other card issuer concerning not only the status of the card
holder's card transactions, but also concerning other matters. For
example, general fraud warnings/alerts can be communicated and even
promotional offers and other targeted marketing messages. In all
cases, the card holder can respond to such messages in real-time
from the card holder's mobile device 110 (e.g., via two-way
messaging).
[0085] Indeed, according to an embodiment of the present invention,
a bank can push deposit account notifications to its enrolled
customers. For example, referring to FIGS. 6A-6C, the bank and/or
the customer can establish a trigger or threshold to automatically
notify the customer when a check drawn on that customer's account
exceeds the threshold (this also has application with respect to
automated teller machine transactions).
[0086] FIG. 6A illustrates an exemplary user interface by which the
threshold can be input either by the bank or the customer. A rules
engine can generate a list of customers to notify, and, via the
appropriate server, push the notifications to all or a preselected
subset of the customers' registered mobile devices.
[0087] FIG. 6B illustrates an exemplary notification pushed to a
customer's device 110 that a check above threshold has been cashed.
With a mere tap on the device screen, the customer can, in
real-time, approve the check or decline it (or call the bank to
discuss with a bank representative)--catching fraudulent
transactions before funds are transferred.
[0088] Referring to FIG. 6C, if the customer declines the check,
the customer can be prompted to submit a fraud claim request.
[0089] According to another advantageous aspect of the present
invention, the issuing banks and other financial institutions can
tap into the enrolled card holders' Internet interactions to obtain
useful metrics regarding such interactions. For example: [0090] The
web browsing history (e.g., websites visited, time spent, and sites
where transactions were conducted) for all enrolled customers can
be analyzed by ranking websites based on fraudulent activity
reported subsequent to a customer visit; websites can then be
classified based on the reported financial fraud ranking or their
risk (this can form a basis for generating a customer risk score
based on browsing habits). [0091] For each website class, average
fraud loss per visit can be determined based on the total fraud
loss associated with a website and the total number of visits for
all customers. [0092] Based on the number of visits to each website
class, a potential customer fraud loss number can be computed by
summing visits to a class multiplied by the average loss per class.
[0093] The potential future fraud loss for a customer at any given
time can be used as a score to evaluate authorization actions that
can be taken by an issuer for all future transactions for a given
customer to minimize the fraud on that customer account. [0094]
Customer purchases per website visited can be computed by combining
browsing history with transaction history. [0095] Average purchases
per site can be computed based on total purchases and the number of
visits. [0096] Cumulative purchases per customer for a given time
period minus the potential fraud loss per customer for the same
time period can yield a customer profit score. [0097] Ranking of
customer profit scores based on credit profiles and delinquency
history can be used for targeted marketing purposes; patterns in
the browsing history can be tied to transaction history and
customer credit profiles to develop sophisticated real-time
promotional offers.
[0098] Accordingly, the embodiments of the present invention
address payment product fraud challenges in a new way (that is not
dependent on merchants) through the registration of customer mobile
devices, identification of rogue transactions and web sites, and
improved customer communications. When a transaction on the
customer's account is initiated from an unapproved device, or is
the result of a customer encounter with a fraudulent website such
as, for example, a phishing site, the bank or other financial
institution can block the transaction, the customer can be
notified, and the customer can provide instructions--all in
real-time. With two-way, real-time messaging between the customer
and the bank, the customer no longer has to call the bank to
approve high-risk transactions, and banks can either allow the
transaction to go through or remove the block so the customer can
re-run the transaction.
[0099] It should be understood that the foregoing subject matter
may be embodied as devices, systems, methods and/or computer
program products. Accordingly, some or all of the subject matter
may be embodied in hardware and/or in software (including firmware,
resident software, micro-code, state machines, gate arrays, etc.).
Moreover, the subject matter may take the form of a computer
program product on a computer-usable or computer-readable storage
medium having computer-usable or computer-readable program code
embodied in the medium for use by or in connection with an
instruction execution system. A computer-usable or
computer-readable medium may be any medium that can contain, store,
communicate, propagate or transport the program for use by or in
connection with the instruction execution system, apparatus, or
device.
[0100] The computer-usable or computer-readable medium may be for
example, an electronic, magnetic, optical, electromagnetic,
infrared, or semiconductor system, apparatus, device or propagation
medium. Computer-readable media may comprise computer storage media
and communication media.
[0101] Computer storage media includes volatile and nonvolatile,
removable and non-removable media implemented in any method or
technology for storage of information such as computer-readable
instructions, data structures, program modules or other data.
Computer storage media includes RAM, ROM, EEPROM, flash memory or
other memory technology that can be used to store information and
that can be accessed by an instruction execution system.
[0102] Communication media typically embodies computer-readable
instructions, data structures, program modules or other data in a
modulated data signal such as a carrier wave or other transport
mechanism and includes any information delivery media (wired or
wireless). A modulated data signal can be defined as a signal that
has one or more of its characteristics set or changed in such a
manner as to encode information in the signal.
[0103] When the subject matter is embodied in the general context
of computer-executable instructions, the embodiment may comprise
program modules, executed by one or more systems, computers, or
other devices. Generally, program modules include routines,
programs, objects, components, data structures and the like, which
perform particular tasks or implement particular abstract data
types. Typically, the functionality of the program modules may be
combined or distributed as desired in various embodiments.
[0104] Those of ordinary skill in the art will understand that the
term "Internet" used herein refers to a collection of computer
networks (public and/or private) that are linked together by a set
of standard protocols (such as TCP/IP and HTTP) to form a global,
distributed network. While this term is intended to refer to what
is now commonly known as the Internet, it is also intended to
encompass variations that may be made in the future, including
changes and additions to existing protocols.
[0105] Further, it should be understood that the term "website"
refers to a computer system that serves informational content over
the Internet. As used herein, the term is generally intended to
encompass both (i) the hardware/software components that serve the
informational content over the network, and (ii) the "back-end"
hardware/software components, including non-standard or specialized
components, that interact with the server components to perform
services for website users.
[0106] It will thus be seen that the objects set forth above, among
those made apparent from the preceding description and the
accompanying drawings, are efficiently attained and, since certain
changes can be made in carrying out the above method and in the
constructions set forth for the system without departing from the
spirit and scope of the invention, it is intended that all matter
contained in the above description and shown in the accompanying
drawings shall be interpreted as illustrative and not in a limiting
sense.
[0107] It is also to be understood that the following claims are
intended to cover all of the generic and specific features of the
invention herein described, and all statements of the scope of the
invention which, as a matter of language, might be said to fall
therebetween.
* * * * *
References