U.S. patent application number 15/465981 was filed with the patent office on 2022-04-21 for identifying fraudulent instruments and identification.
The applicant listed for this patent is STATE FARM MUTUAL AUTOMOBILE INSURANCE COMPANY. Invention is credited to Reena Batra, Bradley A. Craig, Puneit Dua, Elizabeth Flowers, Timothy Kramme, Shanna L. Phillips, Russell Ruestman, Miriam Valero.
Application Number | 20220122071 15/465981 |
Document ID | / |
Family ID | |
Filed Date | 2022-04-21 |
![](/patent/app/20220122071/US20220122071A1-20220421-D00000.png)
![](/patent/app/20220122071/US20220122071A1-20220421-D00001.png)
![](/patent/app/20220122071/US20220122071A1-20220421-D00002.png)
![](/patent/app/20220122071/US20220122071A1-20220421-D00003.png)
![](/patent/app/20220122071/US20220122071A1-20220421-D00004.png)
![](/patent/app/20220122071/US20220122071A1-20220421-D00005.png)
![](/patent/app/20220122071/US20220122071A1-20220421-D00006.png)
![](/patent/app/20220122071/US20220122071A1-20220421-D00007.png)
![](/patent/app/20220122071/US20220122071A1-20220421-D00008.png)
![](/patent/app/20220122071/US20220122071A1-20220421-D00009.png)
![](/patent/app/20220122071/US20220122071A1-20220421-D00010.png)
View All Diagrams
United States Patent
Application |
20220122071 |
Kind Code |
A1 |
Kramme; Timothy ; et
al. |
April 21, 2022 |
IDENTIFYING FRAUDULENT INSTRUMENTS AND IDENTIFICATION
Abstract
In a computer-implemented method, a digital image of a signed
financial instrument or identification card may be received from a
financial institution or merchant computing terminal. The digital
image may be analyzed to identify a type of financial instrument or
identification card, and an originating entity. Expected fields of
the instrument or card may be determined based upon the type and
the originating entity. The digital image may be analyzed to
identify actual fields on the instrument or card, and it may be
determined whether the expected fields match the actual fields to
determine whether a fraudulent field exists on the signed financial
instrument or identification card. If it is determined that no
fraudulent field exists, additional operations may be performed to
determine whether the instrument or card contains fraudulent
characters or content.
Inventors: |
Kramme; Timothy; (Parker,
TX) ; Flowers; Elizabeth; (Bloomington, IL) ;
Batra; Reena; (Alpharetta, GA) ; Valero; Miriam;
(Bloomington, IL) ; Dua; Puneit; (Bloomington,
IL) ; Phillips; Shanna L.; (Bloomington, IL) ;
Ruestman; Russell; (Minonk, IL) ; Craig; Bradley
A.; (Normal, IL) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
STATE FARM MUTUAL AUTOMOBILE INSURANCE COMPANY |
Bloomington |
IL |
US |
|
|
Appl. No.: |
15/465981 |
Filed: |
March 22, 2017 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
62365699 |
Jul 22, 2016 |
|
|
|
62331530 |
May 4, 2016 |
|
|
|
62318423 |
Apr 5, 2016 |
|
|
|
62313196 |
Mar 25, 2016 |
|
|
|
International
Class: |
G06Q 20/40 20060101
G06Q020/40; G06Q 30/00 20060101 G06Q030/00 |
Claims
1. A computer-implemented method of identifying fraudulent
transactions, fraudulent financial instruments, or fraudulent
identification cards, comprising: storing associations of a
plurality of types of signed financial instruments or
identification cards and a plurality of originating entities of the
plurality of types of the signed financial instruments or
identification cards with information about expected fields of the
plurality of types of signed financial instruments or
identification cards, the information about the expected fields
comprising one or more physical field locations of the expected
fields on the associated signed financial instruments or
identification cards, an identification of a type of content
associated with the expected fields, and an expected font of
textual content associated with the expected fields; receiving, by
one or more processors, a digital image of a signed financial
instrument or identification card; determining, by the one or more
processors and from the digital image, (i) a type of the signed
financial instrument or identification card and (ii) an originating
entity of the signed financial instrument or identification card;
determining, by the one or more processors, at least one expected
field of the signed financial instrument or identification card
based upon (i) the type, (ii) the originating entity, and (iii) the
associations; identifying, by the one or more processors, an actual
field in the digital image; determining, by the one or more
processors, whether a first font used for textual content of the
actual field matches the expected font; and determining, by the one
or more processors and based on whether the first font matches the
expected font, whether the actual field is a fraudulent field.
2. (canceled)
3. The computer-implemented method of claim 1, further comprising:
determining allowable content for the at least one expected field;
and comparing, by the one or more processors, content in the actual
field to the allowable content, wherein: the identification card is
a social security card; the expected fields include a field
associated with a location of where a social security number is
printed; and the allowable content is at least one of nine numbers
that comprise a social security number or a range of possible
social security numbers available to an individual based upon a
location and date of their birth.
4. The computer-implemented method of claim 1, further comprising:
determining allowable content for the at least one expected field;
and comparing, by the one or more processors, content in the actual
field to the allowable content, wherein: the signed financial
instrument is a personal check; the expected fields include a field
associated with a location of where a bank routing number is
printed; and the allowable content is a bank routing number.
5. The computer-implemented method of claim 1, further comprising:
determining allowable content for the at least one expected field;
and comparing, by the one or more processors, content in the actual
field to the allowable content, wherein: the signed financial
instrument is a personal check; the at least one expected field
includes a field associated with a location of where a checking
account number is printed; and the allowable content is a checking
account number.
6. The computer-implemented method of claim 1, further comprising:
determining allowable content for the at least one expected field;
and comparing, by the one or more processors, content in the actual
field to the allowable content, wherein: the identification card is
a driver's license; the at least one expected field includes a
field associated with a location of where a driver's license number
is printed; and the allowable content is a driver's license
number.
7. The computer-implemented method of claim 1, further comprising:
determining allowable content for the at least one expected field;
and comparing, by the one or more processors, content in the actual
field to the allowable content, wherein: the identification card is
a passport; the expected fields include a field associated with a
name, date of birth, and expiration date; and the allowable content
includes (i) characters or letters for a name field, and (ii)
numbers for the date of birth and expiration date fields.
8. (canceled)
9. A computer system for identifying fraudulent transactions,
financial instruments, or identification cards, wherein the
computer system comprises one or more transceivers and one or more
processors configured to: store associations of a plurality of
types of signed financial instruments or identification cards and a
plurality of originating entities of the plurality of types of the
signed financial instruments or identification cards with
information about expected fields of the plurality of types of
signed financial instruments or identification cards, the
information about the expected fields comprising one or more
physical field locations of content of the expected fields on the
associated signed financial instruments or identification cards, an
identification of a type of content the content on the associated
signed financial instruments or identification cards associated
with the expected fields, and an expected font of textual content
associated with the expected fields; receive, via the one or more
transceivers and one or more radio links, a digital image of a
signed financial instrument or identification card; determine, from
the digital image, (i) a type of the signed financial instrument or
identification card and (ii) an originating entity of the signed
financial instrument or identification card; determine at least one
expected field of the signed financial instrument or identification
card based upon (i) the type, (ii) the originating entity, and
(iii) the associations; identify an actual field in the digital
image; determine whether a first font used for textual content of
the actual field matches the expected font; and determine, based on
whether the first font matches the expected font, whether the
actual field is a fraudulent field.
10. The computer system of claim 9, wherein the one or more
processors are further configured to: determine allowable content
for the at least one expected field; and compare content in the
actual field to the allowable content, wherein: the identification
card is a social security card; the at least one expected field
includes a field associated with a location of where a social
security number is printed; and the allowable content is at least
one of nine numbers that comprise a social security number or a
range of possible social security numbers available to an
individual based upon at least one of a location of birth or a date
of birth of the individual.
11. The computer system of claim 9, wherein the one or more
processors are further configured to: determine allowable content
for the at least one expected field; and compare content in the
actual field to the allowable content, wherein: the signed
financial instrument is a personal check; the at least one expected
field includes a field associated with a location of where a bank
routing number is printed; and the allowable content is a bank
routing number.
12. The computer system of claim 9, wherein the one or more
processors are further configured to: determine allowable content
for the at least one expected field; and compare content in the
actual field to the allowable content, wherein: the signed
financial instrument is a personal check; the at least one expected
field includes a field associated with a location of where a
checking account is printed; and the allowable content is a
checking account number.
13. The computer system of claim 9, wherein the one or more
processors are further configured to: determine allowable content
for the at least one expected field; and compare content in the
actual field to the allowable content, wherein: the identification
card is a driver's license; the at least one expected field
includes a field associated with a location of where a driver's
license number is printed; and the allowable content is a driver's
license number.
14. The computer system of claim 9, wherein the one or more
processors are further configured to: determine allowable content
for the at least one expected field; and compare content in the
actual field to the allowable content, wherein: the identification
card is a passport; the at least one expected field includes a
field associated with a name, date of birth, and expiration date;
and the allowable content includes (i) characters or letters for a
name field, and (ii) numbers for the date of birth and expiration
date fields.
15. (canceled)
16. A non-transitory, computer-readable medium storing instructions
that, when executed by one or more processors, cause the one or
more processors to: store associations of a plurality of types of
signed financial instruments or identification cards and a
plurality of originating entities of the plurality of types of the
signed financial instruments or identification cards with
information about expected fields of the plurality of types of
signed financial instruments or identification cards, the
information about the expected fields comprising one or more
physical field locations of content of the expected fields on the
associated signed financial instruments or identification cards, an
identification of a type of content the content on the associated
signed financial instruments or identification cards associated
with the expected fields, and an expected font of textual content
associated with the expected fields; receive a digital image of a
signed financial instrument or identification card; determine, from
the digital image, (i) a type of the signed financial instrument or
identification card, and (ii) an originating entity of the signed
financial instrument or identification card; determine at least one
expected field of the signed financial instrument or identification
card based upon (i) the type, (ii) the originating entity, and
(iii) the associations; identify an actual field in the digital
image; determine whether a first font used for textual content of
the actual field matches the expected font; and determine, based on
whether the first font matches the expected font, whether the
actual field is a fraudulent field.
17. The non-transitory, computer-readable medium of claim 16,
wherein the instructions further cause the one or more processors
to: determine allowable content for the at least one expected
field; and compare content in the actual field to the allowable
content, wherein: the identification card is a social security
card; the at least one expected field includes a field associated
with a location of where a social security number is printed; and
the allowable content is nine numbers that comprise a social
security number.
18. The non-transitory, computer-readable medium of claim 16,
wherein the instructions further cause the one or more processors
to: determine allowable content for the at least one expected
field; and compare content in the actual field to the allowable
content, wherein: the signed financial instrument is a personal
check; the expected field includes a field associated with a
location of where a bank routing number is printed; and the
allowable content is a bank routing number.
19. The non-transitory, computer-readable medium of claim 16,
wherein the instructions further cause the one or more processors
to: determine allowable content for the at least one expected
field; and compare content in the actual field to the allowable
content, wherein: the signed financial instrument is a personal
check; the expected field includes a field associated with a
location of where a checking account is printed; and the allowable
content is a checking account number.
20. The non-transitory, computer-readable medium of claim 16,
wherein the instructions further cause the one or more processors
to: determine allowable content for the at least one expected
field; and compare content in the actual field to the allowable
content, wherein: the identification card is a driver's license;
the at least one expected field includes a field associated with a
location of where a driver's license number is printed; and the
allowable content is a driver's license number.
21. The computer-implemented method of claim 1, further comprising:
generating, by the one or more processors and in response to
determining that the actual field is a fraudulent field, an
electronic notification indicating that the fraudulent field exists
on the signed financial instrument or identification card, and
transmitting, by the one or more processors and one or more
transceivers, the electronic notification to a merchant computing
terminal to provide notice of the fraudulent field.
22. The computer-implemented method of claim 1, further comprising:
determining, by the one or more processors and in response to
determining that the actual field is not a fraudulent field,
allowable content for the at least one expected field; identifying,
by the one or more processors and in the digital image, actual
content within the actual field; determining, by the one or more
processors, that the actual content is different from the allowable
content; generating, by the one or more processors, an electronic
notification indicating that the signed financial instrument or
identification card is suspicious, and transmitting, by the one or
more processors and one or more transceivers, the electronic
notification to a computing device of a financial institution or
merchant at which the signed financial instrument or identification
card is being presented.
23. The computer-system of claim 9, wherein one or more processors
are further configured to: determine, in response to determining
that the actual field is not a fraudulent field, allowable content
for the at least one expected field; identify, in the digital
image, content within the actual field; determine that the content
is different from the allowable content; generate an electronic
notification indicating that the signed financial instrument or
identification card is suspicious, and transmit the electronic
notification to a computing device of a financial institution or
merchant at which the signed financial instrument or identification
card is being presented.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This claims the benefit of U.S. Patent Application No.
62/313,196, filed on Mar. 25, 2016 and entitled "Reducing Financial
Fraud Using Machine Learning and Other Techniques," U.S. Patent
Application No. 62/318,423, filed on Apr. 5, 2016 and entitled
"Reducing Financial Fraud Using Machine Learning and Other
Techniques," U.S. Patent Application No. 62/331,530, filed on May
4, 2016 and entitled "Reducing Financial Fraud Using Machine
Learning and Other Techniques," and U.S. Patent Application No.
62/365,699, filed on Jul. 22, 2016 and entitled "Detecting and/or
Preventing Financial Fraud Using Geolocation Data," the disclosures
of which are hereby incorporated herein by reference in their
entireties.
FIELD OF THE DISCLOSURE
[0002] The present disclosure generally relates to financial fraud
and, more specifically, to processing techniques for automatically
detecting document-related fraud.
BACKGROUND
[0003] Financial fraud, in its many forms, is a problem of enormous
magnitude and scope, causing billions of dollars in economic losses
and impacting many millions of people. Types of financial fraud
include use of a lost or stolen card, account takeover, skimming,
chargeback ("friendly") fraud, counterfeiting, forgeries and
application (e.g., loan application) fraud, to name just a few. The
problem only continues to grow as various technological advances,
intended to improve convenience and efficiency in the marketplace,
provide new opportunities for bad actors. For example, an
ever-increasing amount of fraud may be linked to online
transactions made via the Internet.
[0004] Various software applications have been developed to detect
potentially fraudulent transactions. For example, dollar amounts
and geographic locations have generally been used to flag
particular credit or debit card transactions, with cardholders then
being contacted by employees of the card issuer to determine
whether the transactions were indeed fraudulent. To ensure that
most instances of fraud are captured, however, such techniques
generally have a low threshold for triggering a fraud alert. As a
result, numerous fraud alerts are false positives. The prevalence
of false positives leads to a large cost in terms of the drain on
human resources (e.g., calling customers to discuss each suspect
transaction, and/or other manual investigation techniques), and
considerable distraction or annoyance for cardholders. To provide a
solution to these shortcomings in the field of automated fraud
detection, innovative processing techniques capable of reducing
false positives are needed.
[0005] Other conventional processes relating to financial fraud are
likewise resource-intensive. For example, efforts to combat
counterfeiting of financial or other documents (e.g., personal
checks, identification cards used to obtain loans, etc.) may be
typically limited to time-consuming and error-prone human review
(i.e., the "eye test").
BRIEF SUMMARY
[0006] The present embodiments may, inter alia, use new processing
techniques to determine whether physical documents relating to a
financial transaction (e.g., personal checks, identification cards,
etc.) are fraudulent (e.g., counterfeit and/or forged) and/or
should be flagged for further review.
[0007] In one embodiment, a computer-implemented method of
identifying fraudulent transactions, financial instruments, or
fraudulent identification cards may include: (1) receiving, by one
or more processors, a digital image of a signed financial
instrument or identification card from a financial institution or
merchant computing terminal; (2) analyzing, by the one or more
processors, the digital image to identify (i) a type of financial
instrument or identification card, and (ii) an originating entity
of the signed financial instrument or identification card; (3)
determining, by the one or more processors, the expected fields of
the signed financial instrument or identification card based upon
the type, and the originating entity; (4) analyzing, by the one or
more processors, the digital image to identify actual fields on the
signed financial instrument or identification card; (5)
determining, by the one or more processors, whether the expected
fields match the actual fields on the signed financial instrument
or identification card to determine whether a fraudulent field
exists on the signed financial instrument or identification card;
and/or either (6A) in response to determining that a fraudulent
field does exist on the signed financial instrument or
identification card, (i) generating, by the one or more processors,
an electronic notification indicating that a fraudulent field
exists on the signed financial instrument or identification card,
and (ii) transmitting, by the one or more processors and one or
more transceivers, the electronic notification to the merchant
computing terminal to provide notice of the fraudulent field, or
(6B) in response to determining that a fraudulent field does not
exist on the signed financial instrument or identification card,
(i) determining, by the one or more processors, allowable content,
or an allowable range of content or characters, for the expected
fields, (ii) analyzing, by the one or more processors, the digital
image to identify actual characters or content within the actual
fields on the signed financial instrument or identification card,
(iii) comparing, by the one or more processors, the actual
characters or content within an actual field with the allowable
content, or the allowable range of content or characters, for the
corresponding expected field to determine whether fraudulent
characters or content are in an expected field, (iv) in response to
determining that fraudulent content exists in an expected field,
generating, by the one or more processors, an electronic
notification detailing the fraud or why the financial instrument or
identification card is suspicious, and (v) transmitting, by the one
or more processors and one or more transceivers, the electronic
notification to a computing device of a financial institution or
merchant at which the signed financial instrument or identification
card is being presented to provide notice of fraudulent characters
or content. The method may include additional, less, or alternate
actions, including those discussed elsewhere herein.
[0008] In another embodiment, a computer system for identifying
fraudulent transactions, financial instruments, or identification
cards includes one or more transceivers and one or more processors
configured to: (1) receive, via the one or more transceivers and
one or more radio links, a digital image of a signed financial
instrument or identification card from a financial institution or
merchant computing terminal; (2) analyze the digital image to
identify (i) a type of financial instrument or identification card,
and (ii) an originating entity of the signed financial instrument
or identification card; (3) determine the expected fields of the
signed financial instrument or identification card based upon the
type, and the originating entity; (4) analyze the digital image to
identify actual fields on the signed financial instrument or
identification card; (5) determine whether the expected fields
match the actual fields on the signed financial instrument or
identification card to determine whether a fraudulent field exists
on the signed financial instrument or identification card; and/or
(6) in response to determining that a fraudulent field does not
exist on the signed financial instrument or identification card,
(i) determine allowable content, or an allowable range of content
or characters, for the expected fields, (ii) analyze the digital
image to identify actual characters or content within the actual
fields on the signed financial instrument or identification card,
(iii) compare the actual characters or content within an actual
field with the allowable content, or the allowable range of content
or characters, for the corresponding expected field to determine
whether fraudulent characters or content are in an expected field,
(iv) in response to determining that fraudulent content exists in
an expected field, generate an electronic notification detailing
the fraud or why the financial instrument or identification card is
suspicious, and (v) transmit, via the one or more transceivers, the
electronic notification to a computing device of a financial
institution or merchant at which the signed financial instrument or
identification card is being presented to provide notice of
fraudulent characters or content. The computer system may include
additional, less, or alternate functionality, including that
discussed elsewhere herein.
[0009] In another embodiment, a non-transitory, computer-readable
medium stores instructions that, when executed by one or more
processors, cause the one or more processors to: (1) receive a
digital image of a signed financial instrument or identification
card from a financial institution or merchant computing terminal;
(2) analyze the digital image to identify (i) a type of financial
instrument or identification card, and (ii) an originating entity
of the signed financial instrument or identification card; (3)
determine the expected fields of the signed financial instrument or
identification card based upon the type, and the originating
entity; (4) analyze the digital image to identify actual fields on
the signed financial instrument or identification card; (5)
determine whether the expected fields match the actual fields on
the signed financial instrument or identification card to determine
whether a fraudulent field exists on the signed financial
instrument or identification card; and/or (6) in response to
determining that a fraudulent field does not exist on the signed
financial instrument or identification card, (i) determine
allowable content, or an allowable range of content or characters,
for the expected fields, (ii) analyze the digital image to identify
actual characters or content within the actual fields on the signed
financial instrument or identification card, (iii) compare the
actual characters or content within an actual field with the
allowable content, or the allowable range of content or characters,
for the corresponding expected field to determine whether
fraudulent characters or content are in an expected field, (iv) in
response to determining that fraudulent content exists in an
expected field, generate an electronic notification detailing the
fraud or why the financial instrument or identification card is
suspicious, and (v) transmit the electronic notification to a
computing device of a financial institution or merchant at which
the signed financial instrument or identification card is being
presented to provide notice of fraudulent characters or
content.
BRIEF DESCRIPTION OF THE DRAWINGS
[0010] The Figures described below depict various aspects of the
systems and methods disclosed herein. It should be understood that
each Figure depicts an embodiment of a particular aspect of the
disclosed systems and methods, and that each of the Figures is
intended to accord with a possible embodiment thereof.
[0011] FIG. 1 depicts an exemplary environment in which techniques
for fraud detection, verification and/or classification may be
implemented, according to one embodiment.
[0012] FIG. 2 depicts an exemplary process flow for machine
learning of fraud detection, verification and/or classification
rules, according to one embodiment.
[0013] FIGS. 3A-3F depict exemplary process flows for machine
learning of particular types of fraud detection, verification
and/or classification rules, according to different
embodiments.
[0014] FIGS. 4A-4F depict exemplary factors and algorithms that may
be used in connection with various fraud detection, verification
and/or classification rule sets, according to different
embodiments.
[0015] FIG. 5 depicts a flow diagram of an exemplary method for
facilitating the detection of document-related fraud, according to
one embodiment.
[0016] FIGS. 6 and 7 illustrate exemplary computer-implemented
methods of identifying potential fraud associated with financial
instruments or identification cards based upon digital image
analysis and/or machine learning techniques.
[0017] FIG. 8 depicts an exemplary computer system in which the
techniques described herein may be implemented, according to one
embodiment.
DETAILED DESCRIPTION
I. Exemplary Fraud Detection and/or Classification
[0018] The embodiments described herein relate to, inter alia,
wholly or partially automated detection, verification and/or
classification of financial fraud. For ease of explanation, and
unless otherwise clearly indicated by the context of usage,
"detecting" or "determining" fraud may be used herein to refer to
initially flagging fraudulent (or potentially fraudulent) activity,
to verifying/confirming that suspect/flagged activity was indeed
fraudulent, or generally to both. The systems and techniques
described herein may be used, for example, to identify, prevent
and/or quantify/measure instances of lost or stolen card use,
account takeover, counterfeiting, skimming, chargeback ("friendly")
fraud, collusive merchant fraud, application (e.g., loan
application) fraud, mortgage fraud, and/or one or more other types
of fraud relating to existing and/or potential financial
transactions and/or accounts. Moreover, those skilled in the art
will appreciate that at least some of the technical advancements
described below (and/or shown in the accompanying figures) are not
necessarily restricted to the financial field.
[0019] In some embodiments, a fraud detection and/or classification
system may analyze data relating to a number of existing or
potential financial accounts. The analysis/processing may be
performed in batch processing operations, or substantially in
real-time (e.g., as the data is generated and/or as financial
transactions occur, etc.), and the data may be obtained from a
variety of sources based upon the particular embodiment and/or
scenario. In one embodiment, for example, data from financial
account records may be analyzed, along with data indicating online
activity of an account holder, location data (e.g., global
positioning satellite (GPS) data from a smartphone or vehicle of
the account holder) and/or other data, to determine whether a
particular financial transaction was fraudulent or likely
fraudulent. The analysis may be performed automatically after the
transaction has been made, or may be performed in response to a
person or algorithm flagging the transaction as a potentially
fraudulent one, for example.
[0020] The analysis may include determining whether the account
holder has expressed interest in the object (e.g., product or
service) of the transaction or the merchant, and/or determining
whether the transaction is consistent with spending patterns
associated with the account holder (e.g., spending patterns
identified using the account holder's transaction records), for
example. In the case of multiple account holders (e.g. multiple
credit or debit card holders), accuracy may be improved by
identifying spending patterns at the individual level rather than,
or in addition to, at the aggregate account level. For example, a
maximum amount of money typically spent in a single transaction
(e.g., over the course of a one-month window, etc.) may be
determined for each of two cardholders listed on a single account,
and the maximum amount for the cardholder who purportedly made a
particular purchase may be compared to the purchase amount to
determine whether fraud is suspected.
[0021] In another exemplary embodiment, financial transaction data
may be analyzed to determine whether a chargeback payment from the
merchant or acquiring bank to a card issuer may be appropriate in
connection with a particular fraudulent transaction. For example,
the card information entry mode (e.g., collecting card information
by inserting the card in a chip reader, swiping the card, manually
entering the card information, etc.), the transaction amount, the
similarity to other transaction(s), and/or other information may be
used to identify which fraudulent transactions are relatively
strong chargeback candidates. The analysis may be performed in
response to a cardholder reporting the transaction as fraudulent,
or after a card issuer has confirmed that the transaction was
fraudulent, for example. For the subset of instances where a
fraudulent transaction has been identified as a chargeback
candidate, a full set of chargeback rules (e.g., devised by a card
network entity such as VISA.RTM., Mastercard.RTM., American
Express.RTM., Discover.RTM., etc.) may be manually or automatically
applied to determine whether a chargeback process should be
initiated (or continued).
[0022] In another exemplary embodiment, application data (e.g.,
information entered in fields of an online application) may be
analyzed in conjunction with search terms entered by a user at a
computing device (e.g., the device from which the user submitted
the application information) to determine whether the person
proffering the application is not the person that he or she
purports to be. For example, if the person submitting an
application had previously used an Internet-based search engine to
search for results associated with the purported applicant's name
(e.g., by using the name as a search term, possibly in addition to
other terms such as "address" and/or "employer," etc.), the
application may be flagged for suspected fraud, and subjected to
additional steps of manual and/or automated review.
[0023] In another exemplary embodiment, a fraud dispute resolution
process (e.g., after a customer has reported a fraudulent or
unrecognized transaction associated with his or her account) may be
facilitated using machine learning techniques. For example, a
machine learning program may be trained, using past dispute
resolution interactions with customers and the associated outcomes
(fraud determinations), to identify various types of information
that, if elicited from customers, tend to be indicative of fraud or
the absence thereof. When fraud is suspected for a particular
transaction, one or more queries for the individual purportedly
making the transaction may be automatically generated using the
types of information identified by the machine learning program, as
well as information about the suspect transaction and/or related
transactions (e.g., dates, locations, amounts, etc.). In some
embodiments and/or scenarios, responses to the queries may be
collected and analyzed to automatically generate additional
queries, with the end goal of discerning whether the transaction
was authorized. For example, queries may include asking whether a
cardholder recalls particular other transactions that appear on the
cardholder's account and were made around the same time as the
suspect transaction (and/or from the same merchant), asking whether
the cardholder recalls being in a particular location at a
particular time (e.g., a location associated with another
transaction appearing on the cardholder's account), whether the
cardholder is aware of a particular billing alias used by a
merchant, and so on.
[0024] In another exemplary embodiment, image data corresponding to
a particular physical document (e.g., a personal or cashier's
check, a driver's license or other identification card, etc.) may
be analyzed, using rules generated by a machine learning program,
to determine whether the document is, or may be, fraudulent (e.g.,
a counterfeit document, and/or a document that includes forged
contents). For example, the machine learning program may be trained
using images of multiple other documents, and fraud determinations
made in connection with those other documents. The machine learning
program may learn which ranges and/or tolerances for dimensions,
fonts, colors, patterns, etc., tend to be most indicative of
counterfeiting, for example. A forgery may be detected based upon
factors relating to the contents of various fields in a document,
such as whether handwriting, a signature, and/or a date format
(e.g., "Jan. 1, 2016," "1/1/16," etc.) matches that used for other
personal checks from a particular account holder, for example. The
fraud determination may be made substantially in real-time to
provide a warning, if needed, to a merchant making a sale, for
example, or may be used to flag a relatively small number of
documents for physical review at a later time, etc.
[0025] In another exemplary embodiment, machine learning techniques
may be used to analyze financial transactions for purposes of
classifying potentially fraudulent behavior (e.g.,
"counterfeiting," "skimming," "lost or stolen card," etc.). For
example, the machine learning program may be trained using fraud
classifications made in connection with multiple other financial
accounts. The machine learning program may learn which types of
data tend to be indicative of different classifications (e.g.,
transaction amount, credit card information entry mode, particular
types of online activity data, etc.), and/or which data values tend
to be indicative of different classifications (e.g., transactions
over $10,000, manual card number entry, etc.), for example. Once a
class of potential fraud has been identified for a particular
transaction, the classification may be used to facilitate or guide
a further, more in-depth analysis or investigation. Alternatively,
or in addition, the classification may be used to calculate one or
more metrics indicating the prevalence of that type of fraud.
[0026] By replacing conventional processing techniques with one or
more of the processing techniques described herein, problems that
have beset the field of fraud detection, classification and/or
prevention in the past may be greatly mitigated or eliminated. For
example, information that has conventionally been overlooked or
ignored may be used to more accurately detect, prevent and/or
classify fraud, and/or to reduce false positive fraud alerts. As
another example, a significant amount of time may be saved by
removing the need for manual investigations, or by reducing the
number of instances where manual investigations are required.
II. Exemplary Environment for Implementing Fraud Detection and/or
Classification Processing Techniques
[0027] FIG. 1 depicts an exemplary environment 10 in which
techniques for fraud detection and/or classification may be
implemented, according to one embodiment. The environment 10 may
include an anti-fraud services system (AFSS) 12, a financial
account management system (FAMS) 14, a card network computing
system 16, a number of cardholder computing devices 20, a number of
merchant computing systems 22, a number of other sources 24, and a
network 26. It is noted that, in other embodiments and/or
scenarios, the environment 10 may include more, fewer and/or
different components than those shown in FIG. 1, such as any of
those discussed elsewhere herein. For example, the environment 10
may include one or more additional financial account management
systems and/or card network computing systems, and/or one or more
of the cardholder computing devices 20 may instead be a computing
device of a holder of a non-card account (e.g., a checking, savings
or loan account) or an applicant for a new account (e.g., a new
loan account). As another example, the environment 10 may include a
computing system of one or more acquiring/merchant banks, and some
or all of the communications with merchant computing systems 22
described below may instead be with the acquiring bank(s).
[0028] FAMS 14 may be associated with (e.g., owned and/or
maintained by) a bank or other financial entity. For example, FAMS
14 may be a bank that acts as a card issuer associated with a
particular type of card network (e.g., VISA.RTM., Mastercard.RTM.,
etc.), and/or an entity that provides loans (e.g., mortgage, home
equity, vehicle, etc.), saving/checking account services, and/or
other financial services to customers. FAMS 14 may maintain an
account records database 30 that stores various kinds of account
information, including account holder information (e.g., names,
addresses, etc.) and data indicative of financial transactions made
in connection with each account (e.g., dates, amounts and merchants
for credit or debit card transactions, dates and amounts for
customer deposits and withdrawals, etc.). Account records database
30 may store account information for some or all of the cardholders
associated with cardholder computing devices 20, for example. While
shown in FIG. 1 as a single entity within FAMS 14, it is understood
that account records database 30 may, in some embodiments, be
distributed across multiple databases and/or multiple
physical/hardware memories, and/or may be wholly or partially
external to (e.g., remote from) FAMS 14.
[0029] AFSS 12 may generally provide services that help to detect
and/or classify fraudulent activity in connection with existing
and/or potential (e.g., applied for) financial accounts, such as
the accounts managed by FAMS 14. In some embodiments, AFSS 12 is
included within FAMS 14. As seen in FIG. 1, AFSS 12 may include a
network interface 32, a memory 34, and a fraud
detection/classification unit 36.
[0030] Network interface 32 may include hardware, firmware and/or
software configured to enable AFSS 12 to wirelessly exchange
electronic data with one or more other components of environment 10
via network 26. For example, network interface 32 may include an
Ethernet port, a modem, a router, and/or one or more other ports
and/or transceivers for one or more other wired and/or wireless
communication technologies.
[0031] Memory 34 may be a computer-readable, non-transitory storage
unit or device, or collection of units/devices, and may include
persistent (e.g., hard disk) and/or non-persistent memory
components. Memory 34 may store instructions that are executable on
one or more processors of AFSS 12 (not shown in FIG. 1) to perform
various operations, including the instructions of various software
applications and data generated and/or used by such
applications.
[0032] Card network computing system 16 may be a computing system
(e.g., one or more servers) of a credit and/or debit card network
entity, such as VISA.RTM. or Mastercard.RTM., for example. In some
embodiments and/or scenarios where the card network entity also
acts as the issuer (e.g., American Express.RTM. or Discover.RTM.),
card network computing system 16 may include FAMS 14. Card network
computing system 16 may provide various services to FAMS 14 and/or
AFSS 12. For example, card network computing system 16 may provide
electronic updates to chargeback rules, fraud scores for particular
customers and/or transactions, and so on.
[0033] Each of cardholder computing devices 20 may be a computing
device of a respective holder of a credit or debit card account
managed by FAMS 14. For example, one or more of cardholder
computing devices 20 may be desktop computers, laptop computers,
tablet computers, smartphones, smart watches, and so on. The
cardholders (e.g., credit or debit card account holders) may use
cardholder computing devices 20 to access (e.g., view, modify,
etc.) their account information stored in account records database
30 online via network 26. In some embodiments where AFSS 12 detects
and/or classifies activity not related to credit or debit card
fraud (e.g., a fraudulent application for a home equity loan,
etc.), cardholder computing devices 20 may instead be computing
devices of other types of customers or potential customers, such as
holders of non-card-based accounts, or individuals who have
submitted an online application for a loan, etc., as discussed
further below. In some of these embodiments, the environment 10 may
omit card network computing system 16.
[0034] Each of merchant computing systems 22 may include one or
more computing devices associated with a particular provider of
products and/or services. For example, some or all of merchant
computing systems 22 may include servers associated with online
retailers. Alternatively, or additionally, some or all of merchant
computing systems 22 may include point-of-sale terminal devices
providing credit and/or debit card payment processing features for
"card present" transactions. In some embodiments where AFSS 12
detects and/or classifies activity not related to customer
purchases (e.g., if AFSS 12 only detects loan application fraud,
etc.), the environment 10 may omit merchant computing systems
22.
[0035] The other sources 24 may include computing devices and/or
systems associated with sources of one or more other types of
information. For example, other sources 24 may include vehicle
telematics systems (e.g., installed in vehicles of cardholders
associated with cardholder computing devices 20), one or more
Internet service providers (ISPs) (e.g., ISPs providing Internet
access to some or all cardholders), "smart home" system devices
(e.g., installed in homes of some or all cardholders), and/or other
systems/devices. In some embodiments, the environment 10 does not
include the other sources 24.
[0036] Network 26 may communicatively couple some or all of the
components shown in FIG. 1. For example, FAMS 14 may use network 26
to communicate with AFSS 12, card network computing system 16,
cardholder computing devices 20 and/or merchant computing systems
22. As another example, AFSS 12 may use network 26 to communicate
with FAMS 14, card network computing system 16, cardholder
computing devices 20, merchant computing systems 22 and/or one or
more of the other sources 24. While shown as a single entity in
FIG. 1, network 26 may include multiple communication networks of
one or more types (e.g., one or more wired and/or wireless local
area networks (LANs), and/or one or more wired and/or wireless wide
area networks (WANs) such as the Internet). Moreover, network 26
may use partially or entirely distinct network components to
support communications between different endpoints or computing
devices, such as wireless communication or data transmission over
one or more radio frequency links and/or wireless communication
channels. For example, the portion(s) of network 26 used for
communications between FAMS 14 and AFSS 12 may be the same as, or
different than, the portion(s) of network 26 used for
communications between FAMS 14 and one or more of cardholder
computing devices 20 over one or more radio links or wireless
communication channels, or between AFSS 12 and one or more of the
other sources 24, etc. Those skilled in the art will appreciate
different types of networks that are appropriate for network 26,
depending upon, for example, how AFSS 12, FAMS 14 and/or other
components of environment 10 are localized or distributed across a
relatively large geographic area.
[0037] Generally, fraud detection/classification unit 36 of AFSS 12
may detect fraudulent activity, confirm whether suspected or
reported fraudulent activity is truly fraudulent, and/or classify
fraudulent or suspected fraudulent activity. For example, fraud
detection/classification unit 36 may analyze each transaction
stored in account records database 30 to determine whether that
transaction is, or potentially is, fraudulent. Alternatively, fraud
detection/classification unit 36 may analyze only those
transactions that were flagged as possibly being fraudulent (e.g.,
by a cardholder calling in to report an unauthorized and/or
unrecognized transaction, or by FAMS 14 or AFSS 12 generating a
preliminary fraud alert after applying an initial set of rules to a
transaction, etc.). Fraud detection/classification unit 36 may
also, or instead, support additional functionality, such as that
described below in connection with the various components of fraud
detection/classification unit 36 shown in FIG. 1.
[0038] As seen in FIG. 1, fraud detection/classification unit 36
may include a machine learning (ML) rule generator 40, an external
data collection unit 42, a behavior analysis unit 44, a dispute
resolution unit 46, a chargeback analysis unit 50, an image
analysis unit 52, a classification unit 54, and/or a notification
unit 56. In other embodiments, fraud detection/classification unit
36 may include more, fewer and/or different components/units than
those shown in FIG. 1. In some embodiments, each of ML rule
generator 40, external data collection unit 42, behavior analysis
unit 44, dispute resolution unit 46, chargeback analysis unit 50,
image analysis unit 52, classification unit 54, notification unit
56, and/or other units or components of fraud
detection/classification unit 36 may be a software component stored
in memory 34 and implemented by one or more processors of one or
more computing devices (e.g., servers) included in AFSS 12.
[0039] ML rule generator 40 may generally analyze various types of
data to generate and/or update fraud detection and/or
classification rules to be applied by fraud
detection/classification unit 36 and stored in an ML rules database
58. As discussed in further detail below, the rules may be used to
detect and/or classify a single type or category of fraudulent
activity, or may be used broadly in connection with multiple types
or categories of fraudulent activity. ML rule generator 40 may
implement any suitable type or types of machine learning. For
example, ML rule generator 40 may implement supervised learning
techniques, such as decision trees, regression-based models,
support vector machines (SVMs) and/or neural networks, and/or
unsupervised learning techniques such as Dirichlet process mixture
models and/or k-means clustering. Other machine learning techniques
are also possible, such as techniques utilizing Bayesian networks,
"deep learning" techniques, and so on. While shown in FIG. 1 as a
single entity within AFSS 12, it is understood that ML rules
database 58 may, in some embodiments, be distributed across
multiple databases and/or multiple physical/hardware memories,
and/or may be wholly or partially external to (e.g., remote from)
AFSS 12.
[0040] External data collection unit 42 may generally collect, via
network interface 32 and/or from sources internal to AFSS 12,
information from various sources (e.g., FAMS 14, cardholder
computing devices 20, other sources 24, etc.), and provide that
data to other portions of AFSS 12 as needed (e.g., to ML rule
generator 40 to generate and/or update rules, and/or to behavior
analysis unit 44, dispute resolution unit 46, chargeback analysis
unit 50, image analysis unit 52 and/or classification unit 54 to
detect and/or classify fraudulent activity). Some data may be
collected indirectly. For example, FAMS 14 may collect transaction
data from merchant computing systems 22 (and/or from acquiring
banks associated with one or more of merchant computing systems
22), and external data collection unit 42 may then collect that
data from the account records database 30 of FAMS 14.
[0041] Once an initial set of rules has been generated and stored
in ML rules database 58, those rules may dictate some or all of the
types of data gathered by external data collection unit 42. In some
embodiments, however, external data collection unit 42 collects a
broad set of data types that may or may not be relevant to fraud
determination or classification, and ML rule generator 40
continually analyzes that data to determine which data types are
most predictive of fraud and/or fraud type/class.
[0042] Behavior analysis unit 44 may generally analyze
cardholder-related (or other customer-related) information to
identify patterns of behavior, which may then be used by fraud
detection/classification unit 36 to detect and/or classify
fraudulent activity. For example, behavior analysis unit 44 may
analyze information obtained from account records database 30 to
identify spending patterns associated with different cardholders.
The operation of behavior analysis unit 44, including the types of
information analyzed and the ways in which that information is used
to arrive at a result (e.g., a pattern of behavior), may be
dictated by the rules stored in ML rules database 58.
[0043] Data indicative of the behavior patterns identified by
behavior analysis unit 44 may be stored in an account holder
behaviors database 60, for example. While shown in FIG. 1 as a
single entity within AFSS 12, it is understood that account holder
behaviors database 60 may, in some embodiments, be distributed
across multiple databases and/or multiple physical/hardware
memories, and/or may be wholly or partially external to (e.g.,
remote from) AFSS 12. In one embodiment, for example, account
holder behaviors database 60 may be included within account records
database 30. In still other embodiments, the environment 10 may not
include account holder behaviors database 60, and behavior patterns
may be only identified by behavior analysis unit 44 "on the fly" as
needed by fraud detection/classification unit 36 (e.g., when needed
to analyze a transaction in view of past spending patterns of a
particular cardholder, etc.).
[0044] In some embodiments, behavior analysis unit 44 may
separately analyze the transactions associated with each account
holder, even if more than one account holder exists for a
particular account. For example, behavior analysis unit 44 may
independently analyze the transactions of each cardholder for a
credit or debit card account in which each spouse has been issued a
credit or debit card in his or her name. Fraud
detection/classification unit 36 may then utilize the individual
spending patterns when detecting and/or classifying fraud. In one
embodiment where fraud detection/classification unit 36 utilizes a
dollar amount threshold to detect likely fraudulent transactions,
for example, a first threshold may be used for transactions made by
a first cardholder listed on an account, and a higher, second
threshold may be used for transactions made by a second cardholder
listed on the account. Further examples are provided below in
connection with FIG. 6, according to various embodiments. In this
manner, fraud detection and/or classification may be made more
precise than would be the case if spending patterns were only
identified at the aggregate level (e.g., using a single dollar
amount threshold, regardless of which cardholder made a particular
transaction).
[0045] Dispute resolution unit 46 may generally analyze financial
transaction data and/or other information to automatically generate
queries for cardholders or other customers. For example, dispute
resolution unit 46 may analyze information obtained from account
records database 30. The generated queries may be designed to help
fraud detection/classification unit 36 determine whether a
particular transaction was fraudulent, or estimate a probability
that the transaction was fraudulent, etc. Dispute resolution unit
46 may also process responses from cardholders/customers, and
automatically generate additional queries based upon those
responses. Examples of the operation of dispute resolution unit 46
are provided below in connection with FIGS. 4E and 9, according to
various embodiments.
[0046] Chargeback analysis unit 50 may generally analyze financial
transaction and/or other information to identify transactions that
are good candidates for chargeback payments. For example,
chargeback analysis unit 50 may analyze information obtained from
account records database 30 to determine whether there is a
relatively high probability that the merchant (or an acquiring
bank) should be responsible for a chargeback payment to a card
issuer associated with FAMS 14. The operation of chargeback
analysis unit 50, including the types of information analyzed and
the ways in which that information is used to arrive at a result
(e.g., flagging a transaction as a chargeback candidate), may be
dictated by the rules stored in ML rules database 58. ML rule
generator 40 may make use of chargeback rules obtained from a card
network entity (e.g., from card network computing system 16), and
stored in chargeback rules database 62, to generate and/or update
the rules applied by chargeback analysis unit 50. Examples of the
operation of chargeback analysis unit 50 are provided below in
connection with FIGS. 4B and 7, according to various
embodiments.
[0047] In some embodiments, transactions flagged by chargeback
analysis unit 50 are subject to further, manual review using the
chargeback rules stored in chargeback rules database 62. In other
embodiments, chargeback analysis unit 50 (or another component of
fraud detection/classification unit not shown in FIG. 1)
automatically, with little or no manual input/assistance, applies
the chargeback rules from chargeback rules database 62 for each
flagged transaction. While shown in FIG. 1 as a single entity
within AFSS 12, it is understood that chargeback rules database 62
may, in some embodiments, be distributed across multiple databases
and/or multiple physical/hardware memories, and/or may be wholly or
partially external to (e.g., remote from) AFSS 12.
[0048] Image analysis unit 52 may generally analyze image data
corresponding to physical documents to identify fraudulent (e.g.,
counterfeit and/or forged) documents, and/or to flag potentially
fraudulent documents for further (e.g., manual) review. For
example, image analysis unit 52 may analyze information obtained
from merchant computing systems 22 to determine whether there is a
relatively high probability that documents presented to the
merchants (e.g., personal checks, identification cards, etc.) are
fraudulent. Image analysis unit 52 may be configured to analyze
only a single type of document, or multiple types of documents. The
operation of image analysis unit 52, including the image
characteristics analyzed and the ways in which the characteristics
may be used to arrive at a result (e.g., flagging a document as
potentially fraudulent), may be dictated by the rules stored in ML
rules database 58. Examples of the operation of image analysis unit
52 are provided below in connection with FIGS. 4F and 10, according
to various embodiments.
[0049] Classification unit 54 may generally analyze broad
categories of data from various sources (e.g., account records
database 30, cardholder computing devices 20, merchant computing
systems 22, and/or other sources 24) to categorize/classify types
of suspected fraudulent financial activity. Classification unit 54
may classify fraudulent activity only within a particular subset of
fraudulent financial activity (e.g., classifying debit and/or
credit card transactions as involving a potential case of
counterfeiting, skimming, lost/stolen card use, chargeback fraud,
etc.), or may classify fraudulent financial activity across a
broader spectrum (e.g., including types of identity theft not
necessarily tied to a single financial transaction, such as
application fraud). In some embodiments, classification unit 54
classifies suspected fraudulent activity in connection with a
particular account or transaction in response to being notified of
suspect activity (e.g., notified by another component of fraud
detection/classification unit 36, or by a manual user input, etc.).
In other embodiments, classification unit 54 itself (or another
component of fraud detection/classification unit 36) identifies
suspect activity before classification unit 54 classifies that
activity. Examples of the operation of classification unit 54 are
provided below in connection with FIGS. 4C and 11, according to
various embodiments.
[0050] Notification unit 56 may generally provide alerts,
confirmations, and/or other notifications to various individuals
(e.g., customers, bank employees associated with FAMS 14, third
party employees associated with AFSS 12, etc.). For example,
notification unit 56 may generate a notification message stating
that a fraud alert associated with a particular transaction is a
false positive, and cause network interface 32 to send the message
to a computer terminal or to FAMS 14 for display to a system user.
As another example, notification unit 56 may cause network
interface 32 to send other flagged transactions and/or documents
(e.g., chargeback candidates identified by chargeback analysis unit
50, documents that image analysis unit 52 has identified as
potentially fraudulent, etc.) to a computer terminal or FAMS 14 for
display to a system user. As yet another example, notification unit
56 may cause network interface 32 to send queries generated by
dispute resolution unit 46 to various ones of cardholder computing
devices 20 for display to cardholders.
[0051] The operation of various components of the environment 10
shown in FIG. 1, according to different embodiments and/or
scenarios, will be described further below in connection with the
remaining figures.
III. Exemplary Process Flows for Machine Learning of Fraud
Detection and/or Classification Rules
[0052] As discussed above, ML rule generator 40 may generate and/or
update rules that are used for one or more of a variety of
different purposes relating to fraud detection and/or
classification. FIG. 2 depicts one generalized, example process
flow 80 for machine learning that may be implemented by ML rule
generator 40, and possibly one or more other components of fraud
detection/classification unit 36.
[0053] In the process flow 80, multi-account data 82 may represent
data associated with multiple financial accounts, each with one or
more account holders. The financial accounts may be existing or
potential accounts, and the account holders may include holders of
accounts and/or potential holders of potential accounts. For
example, the multi-account data 82 may include existing and/or
applied-for credit card accounts, debit card accounts, savings
accounts, checking accounts, investment accounts, loan accounts,
etc.
[0054] Depending upon the embodiment, the multi-account data 82 may
include one or more different types of information obtained (e.g.,
by external data collection unit 42 of FIG. 1) from one or more of
FAMS 14, cardholder computing devices 20, merchant computing
systems 22, and/or other sources 24. For example, the multi-account
data 82 may include transaction data (e.g., transaction dates,
amounts, locations, etc.) from account records database 30 of FAMS
14, data indicative of Internet Protocol (IP) addresses of
cardholder computing devices 20 and/or devices in merchant
computing systems 22, Internet browsing and/or search history data
from cardholder computing devices 20 (or from an ISP computer
system included in other sources 24, etc.), vehicle telematics data
from telematics systems of cardholder vehicles, home occupancy
and/or usage data (e.g., smart appliance data) from smart home
systems of cardholders, autonomous or smart vehicle data, vehicle
navigation system data, mobile device data, mobile device and/or
vehicle GPS data, and/or one or more other types of data. In some
embodiments, the multi-account data 82 only includes data that
account holders or potential account holders have expressly
consented to share with an entity associated with FAMS 14 and/or
AFSS 12 (e.g., in exchange for fraud protection services). In
certain other embodiments, however, express consent is only needed
for certain types of information, such as browsing history
information, vehicle telematics data, etc.
[0055] The multi-account data 82 may be associated with multiple
fraud determination labels. The labels may simply reflect whether
or not fraud existed (e.g., "fraud" or "no fraud"), or may also
indicate a type or class of fraud (e.g., "counterfeiting," "lost or
stolen card use," etc.), for example. In one embodiment, each of a
number of data sets in the multi-account data 82 is associated with
such a label, and includes data relating to a particular financial
transaction, financial account, loan application, etc., for which
the fraud determination was made (e.g., after a manual and/or
automated fraud investigation). The labels may include final fraud
determinations that were made via earlier iterations of the process
flow 80, and/or external to the process flow 80.
[0056] To provide a more detailed example, a first data set
associated with a "card present" credit card transaction may
include data describing that transaction (e.g., from account
records database 30) and data indicative of the cardholder's online
browsing activity (e.g., from one of cardholder computing devices
20) for the 15 days immediately preceding the transaction, and be
labeled "confirmed fraud." A second data set, associated with
another "card present" transaction (for the same account, or for a
different account), may include the same general types of data but
be labeled "no fraud," and so on. In some embodiments and/or
scenarios, the same data may appear in, or be used by, two or more
of the data sets. If the two "card present" transactions described
above are both associated with the same account, for example, and
if the second transaction occurred less than 15 days after the
first transaction, some of the same online activity data may be
shared by the first and second data sets.
[0057] At a process stage 84, the multi-account data 82 may be
analyzed to generate fraud detection and/or classification rules
(e.g., to be stored in ML rules database 58). Any suitable type of
supervised machine learning program/technique(s) may be used, such
as SVMs, neural networks, logistic regression, etc. Generally,
process stage 84 may serve to identify which type(s) of data is/are
probative of whether fraud has occurred (and/or the type/category
of fraud that may have occurred), and to determine the data values
and/or combinations that are probative of whether fraud has
occurred (and/or the type/category of fraud that may have
occurred). By analyzing many (e.g., thousands) of positively and
negatively labeled data sets in the multi-account data 82, for
example, process stage 84 may learn that certain spending patterns
within a threshold time of a transaction tend to indicate that the
cardholder made the transaction (e.g., thereby indicating that
fraud has not occurred, or that a fraud report is itself fraudulent
or mistaken, etc.), that certain types of online searches by a
cardholder (e.g., including a descriptor of a product purchased in
the transaction, or a name of the merchant, etc.) tend to indicate
that the cardholder made the transaction, that the cardholder's
distance from the site of a "card present" transaction (e.g., as
determined from GPS information provided by the cardholder's
smartphone, wearable electronics, or vehicle) relates to the
probability of fraudulent activity according to a particular
equation, and so on. Other specific examples of such rules, and how
those rules may be generated, are discussed below in connection
with FIGS. 3A-3F and 4A-4F, according to various embodiments.
[0058] At process stage 86, the rules generated or updated at
process stage 84 may be applied to first account data 90 associated
with a particular account and customer(s) (e.g., a customer
associated with a particular one of computing devices 20). The
types of data included in first account data 90 may depend upon
which types of data were determined, by process stage 84, to be
relevant to a fraud determination. For example, if the rules give
weight to the amount and date of a financial transaction when
determining whether the transaction is fraudulent, and also give
weight to whether the account holder visits a particular type of
website, then the first account data 90 may include the amount and
date of one or more transactions, as well as data indicative of
visited web sites (e.g., Uniform Resource Locators (URLs) and/or
content of visited websites, etc.). The first account data 90 may
include information obtained (e.g., by external data collection
unit 42) from one or more of FAMS 14, one of cardholder computing
devices 20 associated with the customer holding the first account,
one or more of merchant computing systems 22, and/or one or more of
other sources 24, for example.
[0059] Process stage 86 may output various different types of
information, depending upon the embodiment and/or scenario. For
example, depending upon the content of first account data 90 and
the rules generated or updated at process stage 84, process stage
86 may generate data indicating that a particular financial
transaction associated with first account data 90 is, or is not,
fraudulent or potentially fraudulent. Alternatively, or
additionally, process stage 86 may generate data indicating a
particular classification for fraudulent or suspected fraudulent
activity (e.g., a fraudulent transaction) associated with first
account data 90.
[0060] In some embodiments, further analysis (e.g., a manual
review, or further automated review using additional data sources,
etc.) may be performed at an additional stage, shown in dashed
lines in FIG. 2 as process stage 92. The additional analysis may
then be used to make a final fraud determination (e.g., a final
decision on whether fraud occurred, and/or on the type of fraud
that occurred) at process stage 94. In other embodiments, process
stage 92 is omitted from process flow 80, and process stage 94
merely represents the output of process stage 86. The final
determination made at process stage 94, along with the first
account data 90 used to make that determination, may be fed back
into process stage 84 to provide additional labeled data for
purposes of updating the rules.
[0061] In some embodiments, the process flow 80 includes more,
fewer and/or different stages, such as any of those discussed
elsewhere herein (e.g., in connection with FIGS. 3A-3F). In one
alternative embodiment, process stages 84 and 86 may be combined.
For example, the multi-account data 82 may be unlabeled rather than
labeled (or the labels may be ignored), and the combined process
stage 84, 86 may use unsupervised learning techniques (e.g.,
clustering techniques) to classify anomalous/outlier financial
transactions, accounts, applications, etc., as "suspect" and
needing further analysis.
[0062] More specific, machine learning-based process flows
generally corresponding to process flow 80 of FIG. 2 will now be
described with reference to FIGS. 3A-3F. It is noted, however, that
other process flows are also within the scope of the invention
described herein. Moreover, while FIGS. 3A-3F generally correspond
to embodiments in which supervised machine learning techniques are
used, other embodiments may instead use unsupervised machine
learning techniques, as noted above. In various different
embodiments, fraud detection/classification unit 36 may be
configured to implement only one of the process flows of FIGS.
3A-3F, or may be configured to implement two or more (e.g., all) of
the process flows shown in FIGS. 3A-3F.
A. Exemplary Process Flow for Machine Learning of Fraud Detection
Rules Using Online Activity Data
[0063] Referring first to FIG. 3A, an exemplary process flow 100
may generally be used to detect fraud using customer online
activity data. In the process flow 100, multi-customer online
activity data 102 may represent data associated with the online
activities of a number (e.g., thousands) of customers (e.g., credit
or debit cardholders, checking or saving account holders, etc.).
The multi-customer online activity data 102 may include data
indicating actions that the customers took, and/or web sites
visited by the customers, while the customers were connected to the
Internet via web browsers (e.g., executing on respective ones of
cardholder computing devices 20). For example, the multi-customer
online activity data 102 may include URLs of, and/or content (e.g.,
text) within, web sites visited by customers, search terms entered
by customers using search engine tools, search results presented to
customers by search engine tools, indications of interactive
controls (e.g., virtual buttons) selected by customers on various
web pages, and so on.
[0064] The multi-customer online activity data 102 may include data
obtained (e.g., by external data collection unit 42 of FIG. 1) from
cardholder computing devices 20, from one or more ISPs of other
sources 24, and/or from a third party aggregator of such
information, for example. In some embodiments, the multi-customer
online activity data 102 may only include data that customers have
expressly consented to share with an entity associated with FAMS 14
and/or AFSS 12 (e.g., in exchange for fraud protection services or
other benefits, such as discounts).
[0065] As described above in connection with multi-account data 82
of process flow 80, the multi-customer online account data 102 may
be associated with multiple fraud determination labels. In some
embodiments, each label may be associated with a data set that
includes not only the corresponding portion of multi-customer
online activity data 102, but also one or more other types of data,
such as transaction data (e.g., transaction dates, amounts,
locations, etc.) for each customer from account records database 30
of FAMS 14, data indicative of IP addresses of cardholder computing
devices 20 and/or devices in merchant computing systems 22,
Internet browsing and/or search history data from cardholder
computing devices 20 (or from an ISP computer system included in
other sources 24, etc.), vehicle telematics data from telematics
systems of other sources 24, home occupancy and/or usage data
(e.g., smart appliance data) from smart home systems of other
sources 24, and so on. The labels may include final fraud
determinations that were made via earlier iterations of the process
flow 100, and/or external to the process flow 100. Multi-customer
online account data 102 may include many (e.g., thousands) of
positively and negatively labeled data sets.
[0066] At a process stage 104, the multi-customer online activity
data 102 may be analyzed to generate fraud detection rules (e.g.,
to be stored in ML rules database 58). As described above in
connection with process stage 84 of process flow 80, any suitable
type of supervised machine learning program/technique(s) may be
used. Generally, process stage 104 may serve to identify which
type(s) of online activity data is/are probative of whether fraud
has occurred, and to determine the data values and/or combinations
that are probative of whether fraud has occurred. While not shown
in FIG. 3A, the fraud detection rules may not only detect fraud,
but also classify fraud (e.g., as described below in connection
with FIG. 3C), in some embodiments.
[0067] At process stage 106, the rules generated or updated at
process stage 104 may be applied to first customer online activity
data 110. The first customer online activity data 110 may be
associated with a particular customer, such as a customer
associated with a particular one of computing devices 20, for
example. The types of data included in first customer online
activity data 110 may depend upon which types of online activity
data were determined, by process stage 104, to be relevant to a
fraud determination. For example, the first customer online
activity data 110 may include information obtained (e.g., by
external data collection unit 42) from one of cardholder computing
devices 20 (i.e., the device associated with the first customer),
and/or from an ISP of other sources 24. Some specific examples of
rules that may be generated by process stage 104, and applied at
process stage 106, are described below in connection with FIG.
4A.
[0068] Process stage 106 may output various different types of
information, depending upon the embodiment and/or scenario. For
example, depending upon the content of first customer online
activity data 110 and the rules, process stage 106 may generate
data indicating that a particular financial transaction associated
with the first customer is, or is not, fraudulent or potentially
fraudulent. Alternatively, or additionally, process stage 106 may
generate data indicating a particular classification of fraudulent
or potentially fraudulent activity associated with first customer
online activity data 110.
[0069] In some embodiments, further analysis (e.g., a manual
review, or further automated review using additional data sources,
etc.) is performed at an additional stage, shown in dashed lines in
FIG. 3A as process stage 112. The additional analysis may then be
used to make a final fraud determination (e.g., a final decision on
whether fraud occurred, and/or on the type of fraud that occurred)
at process stage 114. In other embodiments, process stage 112 is
omitted from process flow 100, and process stage 114 merely
represents the output of process stage 106.
[0070] The final determination made at process stage 114, along
with the first customer online activity data 110 (and any other
data) used to make that determination, may be fed back into process
stage 104 to provide additional labeled data for purposes of
updating the rules. In some embodiments, a preliminary fraud
determination made at process stage 106 is also fed back into
process stage 104, to allow the machine learning program to
determine and improve upon past performance/accuracy.
B. Exemplary Process Flow for Machine Learning of Chargeback
Candidate Detection Rules
[0071] Referring next to FIG. 3B, an exemplary process flow 120 may
generally be used to identify the financial transactions for which
chargebacks (e.g., post-transaction payments from merchants, or
acquiring/merchant banks, back to the issuer to return proceeds
from transactions) are appropriate. In the process flow 120,
multi-account transaction data 122 may represent data associated
with the financial transactions involving the accounts of a number
(e.g., thousands) of credit or debit cardholders. The multi-account
transaction data 122 may include information such as transaction
dates, transaction amounts, merchant names (and/or aliases)
associated with the transaction, information relating to how the
card information was collected by the merchant (e.g., by swiping,
an EMV chip reader, manual entry of the card number, etc.),
geographic locations of "card present" transactions, and so on. The
multi-account transaction data 122 may include data obtained (e.g.,
by external data collection unit 42 of FIG. 1) from merchant
computing systems 22 and/or from acquiring/merchant banks
associated with those merchants, for example.
[0072] Similar to the labels described above in connection with
multi-account data 82 of process flow 80, the multi-account
transaction data 122 may be associated with multiple chargeback
outcome labels. For example, each label may be associated with a
data set that includes the corresponding portion of multi-account
transaction data 122. The outcome labels may include final
chargeback determinations that were made (in connection with the
transactions represented in multi-account transaction data 122) via
earlier iterations of the process flow 120, and/or external to the
process flow 120. Multi-account transaction data 122 may include
many (e.g., thousands) of positively and negatively labeled data
sets.
[0073] At a process stage 124, the multi-account transaction data
122 may be analyzed to generate chargeback candidate detection
rules (e.g., to be stored in ML rules database 58). As described
above in connection with process stage 84 of process flow 80, any
suitable type of supervised machine learning program/technique(s)
may be used. Generally, process stage 124 may serve to identify
which type(s) of transaction data is/are probative of whether,
under the full chargeback rules of the card network entity, a
chargeback is appropriate for a given transaction. Process stage
124 may also determine the transaction data values and/or
combinations that are probative of whether a chargeback is
appropriate for the transaction.
[0074] At a process stage 126, the rules generated or updated at
process stage 124 may be applied to first account transaction data
130 to determine whether a transaction associated with the first
account is a "good" chargeback candidate. Put differently, process
stage 126 may, instead of applying the full chargeback rules of the
card network entity (which may be quite lengthy and complex) to the
facts surrounding the transaction, use various factors and
algorithms developed at process stage 124 to determine whether
there exists a relatively high probability that a chargeback would
be appropriate for the transaction if the full chargeback rules
were applied. The process stage 126 may calculate a percentage
probability that the transaction is one in which a chargeback is
appropriate, for example.
[0075] The first account transaction data 130 may be associated
with the account of a particular cardholder or cardholders, such as
a cardholder associated with a particular one of cardholder
computing devices 20, for example. The types of data included in
first account transaction data 130 may depend upon which types of
transaction-related data were determined, by process stage 124, to
be relevant to a chargeback candidate determination. For example,
the first account transaction data 130 may include information
obtained (e.g., by external data collection unit 42) from one of
merchant computing systems 22 (e.g., the computing system of the
merchant involved in the transaction being analyzed) and/or from an
acquiring/merchant bank associated with that merchant. The first
account transaction data 130 may also include information about one
or more other transactions associated with the first account (e.g.,
data pertaining to other transactions occurring shortly before
and/or after the transaction at issue). Some specific examples of
rules that may be generated by process stage 124, and applied at
process stage 126, are described below in connection with FIG.
4B.
[0076] Process stage 126 may output information indicating whether
the particular transaction represented by first account transaction
data 130 is a "good" candidate for chargeback detection. For
example, process stage 126 may output a percentage probability,
calculated according to the rules generated or updated at process
stage 124, that the transaction is one in which a chargeback is
appropriate. As another example, process stage 126 may output a
binary indicator of whether the transaction is, or is not, a
strong/likely chargeback candidate (e.g., by comparing the
percentage probability to a threshold probability).
[0077] If the transaction is identified as a chargeback candidate
at process stage 126, the full chargeback rules of the card network
entity may be applied at a process stage 132. Process stage 132 may
include manual application of the full chargeback rules, and/or
automated application of the full chargeback rules, in various
different embodiments. Based upon the analysis at process stage
132, a final chargeback determination may be made at a process
stage 134. The final determination made at process stage 134, along
with the first account transaction data 130 (and any other data)
used to make that determination, may be fed back into process stage
124 to provide additional labeled data for purposes of updating the
rules. In some embodiments, the indication of whether the
transaction is a good chargeback candidate generated at process
stage 126 may also be fed back into process stage 124, to allow the
machine learning program to determine and improve upon past
performance/accuracy.
C. Exemplary Process Flow for Machine Learning of Fraud
Classification Rules
[0078] Referring now to FIG. 3C, an exemplary process flow 140 may
generally be used to classify instances of suspected or potential
fraud. For example, the process flow 140 may represent ongoing,
real-time or batch processing of a large amount of data associated
with a large number of potential and/or existing financial accounts
(e.g., all accounts associated with a particular bank, or all
accounts opting in to a fraud protection program, etc.). In this
manner, the process flow 140 may be used to initially flag
situations for closer investigation, and provide one or more
classifications of the type(s) of fraud potentially at issue in
order to narrow or otherwise facilitate the investigation. In other
embodiments, the process flow 140 may be used to provide a narrower
classification (e.g., "skimming") when a broader class of fraud
(e.g., credit card fraud) is already suspected.
[0079] In the process flow 140, multi-account data 142 may
represent data associated with financial accounts of a number
(e.g., thousands) of account holders. The financial accounts may be
existing or potential accounts, and the account holders may include
holders of accounts and/or potential holders of potential accounts.
For example, the multi-account data 142 may include existing and/or
applied-for credit card accounts, debit card accounts, savings
accounts, checking accounts, investment accounts, loan accounts,
etc.
[0080] Depending upon the embodiment, the multi-account data 142
may include one or more different types of information obtained
(e.g., by external data collection unit 42 of FIG. 1) from one or
more of FAMS 14, cardholder computing devices 20, merchant
computing systems 22, and/or other sources 24. For example, the
multi-account data 142 may include transaction data (e.g.,
transaction dates, amounts, locations, etc.) from account records
database 30 of FAMS 14, data indicative of IP addresses of
cardholder computing devices 20 and/or devices in merchant
computing systems 22, Internet browsing and/or search history data
from cardholder computing devices 20 (or from an ISP computer
system included in other sources 24, etc.), vehicle telematics data
from telematics systems of cardholder vehicles, home occupancy
and/or usage data (e.g., smart appliance data) from smart home
systems of cardholders, and/or one or more other types of data.
Some or all data within multi-account data 142 may be information
that account holders or potential account holders have expressly
consented to share with an entity associated with FAMS 14 and/or
AFSS 12 (e.g., in exchange for fraud protection services).
[0081] The multi-account data 142 may be associated with multiple
fraud determination labels, each indicating a type or class of
fraud (e.g., "counterfeiting," "lost or stolen card use,"
"skimming," "chargeback fraud," "application fraud," etc.), or
indicating a lack of fraud, for example. In one embodiment, each of
a number of data sets in the multi-account data 142 is associated
with at least one such classification/label, and includes data
relating to a particular financial transaction, financial account,
loan application, etc., for which the fraud classification or
classifications was/were made (e.g., after a previous iteration of
process flow 140, or after another manual and/or automated fraud
investigation). Multi-account data 142 may include many (e.g.,
thousands) of data sets labeled with various known fraud
classifications.
[0082] At a process stage 144, the multi-account data 142 may be
analyzed to generate fraud classification rules (e.g., to be stored
in ML rules database 58). As described above in connection with
process stage 84 of process flow 80, any suitable type of
supervised machine learning program/technique(s) may be used.
Generally, process stage 144 may serve to identify which type(s) of
transaction data is/are probative of the particular type of fraud
(if any) that has occurred. Process stage 144 may also determine
the data values and/or combinations that are probative of the
particular type of fraud (if any) that has occurred.
[0083] At a process stage 146, the rules generated or updated at
process stage 144 may be applied to first account data 150. The
first account data 150 may be associated with a particular account
and a particular customer (e.g., a cardholder associated with a
particular one of computing devices 20). The types of data included
in first account data 150 may depend upon which types of data were
determined, by process stage 144, to be relevant to fraud
classification. For example, the first account data 150 may include
information obtained (e.g., by external data collection unit 42)
from one or more of FAMS 14, one of cardholder computing devices 20
(i.e., the device associated with the customer holding or applying
for the first account), one or more of merchant computing systems
22, and/or one or more of other sources 24. Some specific examples
of rules that may be generated by process stage 144, and applied at
process stage 146, are described below in connection with FIG.
4C.
[0084] Process stage 146 may output data (e.g., a message or code)
that is used to classify suspected fraudulent activity (in
connection with the account associated with first account data 150)
at a process stage 152. For example, process stage 152 may assign a
classification of "counterfeiting" if process stage 146 determined
that the first account data 150 indicated a number of circumstances
that, according to the rules generated at process stage 144, are
known to be correlated with counterfeiting activity (e.g., two
"card present" transactions occurring in different states within
the same one-hour time period, etc.). In some embodiments and/or
scenarios, two or more classifications may concurrently be assigned
to first account data 150. For example, process stage 146 may
determine a set of probabilities for a set of two or more potential
types of fraud, and process stage 152 may assign each
classification, with each respective probability, to first account
data 150. Moreover, in some embodiments and scenarios, process
stage 152 may assign a classification that corresponds to an
absence of any suspected fraud (e.g., "no fraud").
[0085] At a process stage 154, if process stage 152 assigned a
classification other than one indicating the absence of suspected
fraud, the first account data 150, and/or other information
associated with the account and the suspected class of fraud, may
be analyzed in depth to make a final fraud determination at a
process stage 156. Generally, the fraud classification may be used
to facilitate the analysis at process stage 154, with process stage
154 including manual and/or automated fraud detection techniques.
For example, personnel associated with AFSS 12 may use the fraud
classification(s) to inform their strategy and/or focus with
respect to conducting an in-depth fraud investigation.
[0086] The additional analysis at process stage 154 may then result
in a final fraud determination at process stage 156. The final
determination may indicate both whether fraud occurred and, if so,
the class(es)/type(s) of fraud that occurred. The final
determination made at process stage 156, and information used to
make that determination (e.g., the first account data 150 and
potentially other data), may be fed back into process stage 144 to
provide additional labeled data for purposes of updating the rules.
In some embodiments, the (preliminary) fraud classification made at
process stage 152 may also be fed back into process stage 144 to
help the machine learning program identify instances in which the
preliminary classifications at process stage 152 were incorrect.
Process stage 144 may then update the fraud classification rules in
ways that seek to prevent or reduce such instances in the
future.
D. Exemplary Process Flow for Machine Learning of Application Fraud
Detection Rules
[0087] Referring now to FIG. 3D, an exemplary process flow 160 may
generally be used to detect application fraud. "Application fraud"
may generally refer to fraud in connection with the application for
any type of financial account, loan and/or line of credit (e.g.,
mortgage loan, vehicle loan, small business loan, payday loan, home
equity line of credit, credit card account, debit card account,
checking account, savings account, investment account, etc.). In
some embodiments and/or scenarios, however, the application may be
for non-financial purposes, such as an application for membership
in a particular group or institution, for example.
[0088] In the process flow 160, multi-applicant search history data
162 may represent data associated with the Internet search history
of a number (e.g., thousands) of applicants. The multi-applicant
search history data 162 may include search terms entered by the
applicants using online search engine tools, for example, and/or
the results of such searches (e.g., URLs, titles and/or contents of
search results), for example.
[0089] The multi-applicant search history data 162 may include data
obtained (e.g., by external data collection unit 42 of FIG. 1) from
cardholder computing devices 20, from one or more ISPs of other
sources 24, and/or from a third party aggregator of such
information, for example. In some embodiments, the multi-applicant
search history data 162 only includes data that the applicants have
expressly consented to share with an entity associated with FAMS 14
and/or AFSS 12 (e.g., in exchange for consideration of their
applications).
[0090] As described above in connection with multi-account data 82
of process flow 80, the multi-applicant search history data 162 may
be associated with multiple fraud determination labels. In some
embodiments, each label may be associated with a data set that
corresponds to an application submitted by a particular applicant,
where the data set includes the corresponding portion of
multi-applicant search history data 162 (e.g., the search terms
and/or results associated with the particular application). The
labels may include final fraud determinations that were made via
earlier iterations of the process flow 160, and/or external to the
process flow 160. Multi-applicant search history data 162 may
include many (e.g., thousands) of positively and negatively labeled
data sets.
[0091] At a process stage 164, the multi-applicant search history
data 162 may be analyzed to generate application fraud detection
rules (e.g., to be stored in ML rules database 58). As described
above in connection with process stage 84 of process flow 80, any
suitable type of supervised machine learning program/technique(s)
may be used. Generally, process stage 164 may serve to identify
which type(s) of Internet search-related data is/are probative of
whether application fraud has occurred, and to determine the data
values and/or combinations that are probative of whether
application fraud has occurred.
[0092] At process stage 166, the rules generated or updated at
process stage 164 may be applied to first applicant search history
data 170. The first applicant search history data 170 may be
associated with a particular application and a particular applicant
(e.g., a person associated with a particular one of computing
devices 20), for example. The types of data included in first
applicant search history data 170 may depend upon which types of
Internet search-related data were determined, by process stage 164,
to be relevant to a fraud determination. The first applicant search
history data 170 may include information obtained (e.g., by
external data collection unit 42) from one of computing devices 20
(i.e., the device associated with the first applicant), and/or from
an ISP of other sources 24, for example. Some specific examples of
rules that may be generated by process stage 164, and applied at
process stage 166, are described below in connection with FIG.
4D.
[0093] Process stage 166 may output information indicating whether
fraud is suspected in connection with the application corresponding
to first applicant search history data 170. For example, process
stage 166 may output a percentage probability, calculated according
to the rules generated or updated at process stage 164, that the
application was fraudulently made (e.g., by someone other than the
purported applicant or an authorized representative thereof). As
another example, process stage 166 may output a binary indicator of
whether the application likely was, or likely was not, fraudulently
made (e.g., by comparing a percentage probability to a threshold
probability).
[0094] In some embodiments, further analysis (e.g., a manual
review, or further automated review using additional data sources,
etc.) is performed at an additional stage, shown in dashed lines in
FIG. 3D as process stage 172. The additional analysis may then be
used to make a final fraud determination (e.g., a final decision on
whether application fraud occurred) at process stage 174. In other
embodiments, process stage 172 is omitted from process flow 160,
and process stage 174 merely represents the output of process stage
166. The final determination made at process stage 174, along with
the first applicant search history data 170 (and any other data)
used to make that determination, may be fed back into process stage
164 to provide additional labeled data for purposes of updating the
rules. In some embodiments, a preliminary fraud determination made
at process stage 166 is also fed back into process stage 164, to
allow the machine learning program to determine and improve upon
past performance/accuracy.
E. Exemplary Process Flow for Machine Learning of Fraud Dispute
Resolution Rules
[0095] Referring now to FIG. 3E, an exemplary process flow 180 may
generally be used to facilitate the resolution of fraud disputes
(or potential disputes) with customers/account holders. For
example, the process flow 180 may be used to determine whether a
reportedly unauthorized or fraudulent transaction (e.g., one that
the account holder reported as such when looking at his or her
account statement) was indeed unauthorized or fraudulent. In some
embodiments, the process flow 180 may also, or instead, be used to
determine whether an "unrecognized" transaction (i.e., one that the
account holder does not recall, but does not necessarily report as
fraudulent) was unauthorized or fraudulent.
[0096] In the process flow 180, multi-account data 182 may
represent data associated with financial accounts of a number
(e.g., thousands) of account holders. For example, the
multi-account data 182 may include data associated with financial
transactions relating to credit card accounts, debit card accounts,
savings accounts, checking accounts, etc. For ease of explanation,
FIG. 3E will be described with reference to an embodiment in which
the accounts are credit card accounts.
[0097] In one embodiment, the multi-account data 182 may include
transaction data (e.g., transaction dates, amounts, locations,
etc.) obtained from FAMS 14 (e.g., by external data collection unit
42 of FIG. 1). In some embodiments, however, the multi-account data
182 also includes information obtained from cardholder computing
devices 20, merchant computing systems 22, and/or other sources 24.
For example, the multi-account data 182 may include, in addition to
transaction data from account records database 30 of FAMS 14, data
indicative of IP addresses of cardholder computing devices 20
and/or devices in merchant computing systems 22, Internet browsing
and/or search history data from cardholder computing devices 20 (or
from an ISP computer system included in other sources 24, etc.),
vehicle telematics data from telematics systems of cardholder
vehicles, home occupancy and/or usage data (e.g., smart appliance
data) from smart home systems of cardholders, autonomous vehicle
data, smart vehicle data, mobile device data, vehicle or mobile
device GPS data, and/or one or more other types of data. Some or
all data within multi-account data 182 may be information that
account holders or potential account holders have expressly
consented to share with an entity associated with FAMS 14 and/or
AFSS 12 (e.g., in exchange for fraud protection services).
[0098] As described above in connection with multi-account data 82
of process flow 80, the multi-account data 182 may be associated
with multiple fraud determination labels (e.g., "fraud" and "no
fraud," and/or more complex labels that indicate type/class, such
as "lost/stolen card use," etc.). In some embodiments, each label
may be associated with a data set that includes the corresponding
portion of multi-account data 182. The labels may include final
fraud determinations that were made via earlier iterations of the
process flow 180, and/or external to the process flow 180.
Multi-account data 182 may include many (e.g., thousands) of
positively and negatively labeled data sets.
[0099] At a process stage 184, the multi-account data 182 may be
analyzed to generate query generation rules (e.g., to be stored in
ML rules database 58). As described above in connection with
process stage 84 of process flow 80, any suitable type of
supervised machine learning program/technique(s) may be used.
Generally, process stage 184 may serve to identify which types of
information are probative of whether fraud has occurred, and to
craft rules that formulate queries to ascertain such information
based upon account data.
[0100] For example, process stage 184 may determine that, for a
suspect "card present" transaction, a verified, non-fraudulent
"card present" transaction within 10 miles and 3 hours of the
suspect transaction is probative of whether the suspect transaction
was fraudulent. Based upon this finding, process stage 184 may also
generate a rule specifying that a cardholder should be queried as
to whether he/she can confirm making each "card present"
transaction within 10 miles and 3 hours of the suspect transaction.
As another example, process stage 184 may determine that a merchant
using a billing alias different from its legal and/or
commonly-known name (e.g., by at least some threshold level of
similarity, as measured by number of similar characters, order of
characters, etc.) is probative of whether the cardholder authorized
a transaction associated with that billing alias. Based upon this
finding, process stage 184 may generate a rule specifying that a
cardholder should be queried as to whether he/she is aware of a
billing alias used for a suspect transaction if that billing alias
is sufficiently different from the legal/common name of the
merchant.
[0101] At process stage 186, the rules generated or updated at
process stage 184 may be applied to first account data 190. The
first account data 190 may be associated with a particular
cardholder, such as a cardholder associated with a particular one
of cardholder computing devices 20, for example. The types of data
included in first account data 190 may depend upon which types of
data were determined, by process stage 184, to be relevant to
developing dispute resolution queries. Process stage 186 may
generate a set of one or more queries in accordance with the rules
and the contents of first account data. Some specific examples of
rules that may be generated by process stage 184 and applied at
process stage 186, and the queries that may be generated as a
result, are described below in connection with FIG. 4E.
[0102] At a process stage 192, the generated queries may be sent to
the cardholder in one or more of various ways, such as sending the
queries via SMS text message and/or email, and/or via a web browser
or dedicated application executing on the one of cardholder
computing devices 20 that is associated with the cardholder, for
example. At a process stage 194, responses to the queries are
received from the cardholder (e.g., via inputs made by the
cardholder via the web browser or application, or a responsive SMS
text message or email, etc.). In some embodiments, the rules
generated or updated at process stage 184 specify the manner in
which follow-up queries should be generated based upon the
responses received at process stage 194, and process stages 192 and
194 may be repeated multiple times.
[0103] In some embodiments, further analysis (e.g., a manual
review, or further automated review using additional data sources,
etc.) that makes use of the received responses is performed at an
additional stage, shown in dashed lines in FIG. 3E as process stage
196. The additional analysis may then be used to make a final fraud
determination (e.g., a final decision on whether fraud occurred,
and/or on the type of fraud that occurred) at process stage 198. In
other embodiments, process stage 196 is omitted from process flow
180, and process stage 198 is based upon information from the
cardholder. For example, the questions generated at process stage
192 may "jog" the cardholder's memory, and cause him or her to
indicate that the transaction at issue was authorized. The final
determination made at process stage 198, along with the first
account data 110 (and any other data used at process stage 196),
the queries generated at process stage 186 and/or the responses
received at process stage 194, may be fed back into process stage
184 to provide additional labeled data for purposes of updating the
rules.
F. Exemplary Process Flow for Machine Learning of Document Fraud
Detection Rules
[0104] Referring now to FIG. 3F, an exemplary process flow 200 may
generally be used to detect fraud relating to documents, such as
counterfeit and/or forged documents. The process flow 200 may be
used in connection with various kinds of documents, such as checks
(e.g., personal checks, cashier's checks, etc.), money orders,
treasury bills, identification documents (e.g., social security
cards, driver's licenses, passports, birth certificates, etc.),
certification documents, and so on.
[0105] In the process flow 200, multi-document image data 202 may
represent digital images of a number (e.g., thousands) of physical
documents of one or more types. The multi-document image data 202
may include images in one or more formats, such as raster formats
(e.g., JPEG, TIFF, GIF, BMP, PNG, etc.) and/or vector formats
(e.g., CGM, SVG, etc.), for example. The multi-document image data
202 may include data obtained (e.g., by external data collection
unit 42 of FIG. 1) from merchant computing systems 22 (e.g.,
point-of-sale devices with cameras for document identification)
and/or from FAMS 14 (e.g., images of personal checks), for example.
In some embodiments, the multi-document image data 202 may only
include data representing images that customers (or other
individuals associated with the documents) have expressly consented
to share (e.g., as a prerequisite to making a purchase, or in
exchange for fraud protection services, etc.).
[0106] As described above in connection with multi-account data 82
of process flow 80, the multi-document image data 202 may be
associated with multiple fraud determination labels. In some
embodiments, each label may be associated with data representing a
digital image of a particular document. The labels may include
final fraud determinations (e.g., "fraud" or "no fraud," or more
complex labels such as "forgery," "counterfeit,"
"forgery--signature," "counterfeit--angular line offset(s) outside
tolerance," etc.) that were made via earlier iterations of the
process flow 200, and/or external to the process flow 200.
Multi-document image data 202 may include many (e.g., thousands) of
positively and negatively labeled data sets.
[0107] At a process stage 204, the multi-document image data 202
may be analyzed to generate document fraud detection rules (e.g.,
to be stored in ML rules database 58). As described above in
connection with process stage 84 of process flow 80, any suitable
type of supervised machine learning program/technique(s) may be
used. Generally, process stage 204 may serve to identify which
characteristics of a document are probative of whether the document
is counterfeit, and to determine the ranges, tolerances, etc., that
are probative of whether the document is counterfeit. In some
embodiments, process stage 204 also, or instead, identifies which
characteristics of information entered in document fields are
probative of whether the document was forged (e.g., drafted or
populated by someone other than the person purported to have
drafted or populated the document).
[0108] At process stage 206, the rules generated or updated at
process stage 204 may be applied to first document image data 210.
The first document image data 210 may be digital image data
corresponding to a particular, physical document. The first
document image data 210 may include information obtained (e.g., by
external data collection unit 42) from one of merchant computing
systems 22 (e.g., for real-time verification of an identification
or other document presented during or prior to a sale), or from
FAMS 14 (e.g., for real-time or batch-processing verification of a
personal check prior to clearing the check), for example. Some
specific examples of rules that may be generated by process stage
204, and applied at process stage 206, are described below in
connection with FIG. 4F.
[0109] Process stage 206 may output information indicating whether
fraud is suspected in connection with the document corresponding to
first document image data 210. For example, process stage 206 may
output two percentage probabilities calculated according to the
rules generated or updated at process stage 204, with the first
indicating the likelihood that the document is counterfeit and the
second indicating the likelihood that the document includes forged
content. As another example, process stage 206 may output binary
indicators of whether the document likely is, or likely is not,
counterfeit and/or includes forged content (e.g., by comparing
percentage probabilities to threshold probabilities).
[0110] In some embodiments, further analysis (e.g., a manual
review, or further automated review using additional data sources,
etc.) may be performed at a process stage 212. The additional
analysis may then be used to make a final fraud determination
(e.g., a final decision on whether the document is fraudulent) at
process stage 214. For example, the process stage 206 may act as a
filter, and flag only those documents having a relatively high
probability of being fraudulent. In this manner, a considerably
smaller amount of human and/or processing resources may be consumed
at process stage 212.
[0111] The final determination made at process stage 214, along
with the first document image data 210 used to make that
determination, may be fed back into process stage 204 to provide
additional labeled data for purposes of updating the rules. In some
embodiments, a preliminary fraud determination made at process
stage 206 may also be fed back into process stage 204, to allow the
machine learning program to determine and improve upon past
performance/accuracy.
IV. Exemplary Rules for Fraud Detection and/or Classification
[0112] FIGS. 4A-4F depict exemplary factors and algorithms that may
be used in connection with various fraud detection and/or
classification rules, according to different embodiments. It is
noted that the rule sets corresponding to FIGS. 4A-4F are purely
for purposes of illustration and are not limiting. Particularly in
embodiments where machine learning is utilized, for example, the
algorithms and/or factors may be far more complex, and/or less
intuitive, than some or all of the examples shown in FIGS.
4A-4F.
A. Exemplary Fraud Detection Rule Set Using Online Activity
[0113] Referring first to FIG. 4A, an exemplary rule set 220 (e.g.,
generated at process stage 104 of FIG. 3A) may use various factors
relating to online activity of a cardholder to detect fraud in
connection with a particular credit or debit card transaction. The
rule set 220 may correspond to a particular embodiment and scenario
in which the transaction at issue is a "card present" transaction,
and in which the rule set 220 seeks to determine whether the
cardholder made or otherwise authorized the transaction. The rule
set 220 may be incorporated into a review process that is generally
applied to all transactions, a review process applied only to those
transactions that were flagged by a preliminary fraud alert, or a
review process applied only after a cardholder reports the
transaction as unauthorized, for example.
[0114] The factors considered under the rule set 220 may include a
number of interest-based factors 222 and a number of location-based
factors 224. The interest-based factors 222 may relate to the
cardholder's interest (or non-interest) in a product or service
purchased via the transaction, and/or the merchant providing the
product or service, while the location-based factors 224 may relate
to the cardholder's location or probable location.
[0115] As seen in FIG. 4A, the interest-based factors 222 may
include: (1) whether the cardholder searched online for the
specific product or service purchased via the transaction at issue
(e.g., by determining whether search terms entered by the
cardholder included the name of the product or service involved in
the transaction, or included a description of the product or
service, etc.); (2) whether the cardholder visited a website
associated with the merchant (e.g., by comparing URLs of web sites
visited by the cardholder to a known URL of the merchant's website,
or by searching the contents of websites visited by the cardholder
for the merchant's name, etc.); (3) whether the cardholder endorsed
the merchant, or the product or service provided by the merchant,
via a social media account of the cardholder (e.g., by determining
whether the cardholder "liked" the merchant, product or service via
his or her Facebook.RTM. account, etc.); (4) whether the cardholder
visited a website associated with a competitor of the merchant
(e.g., by comparing URLs of web sites visited by the cardholder to
known URLs of known competitors' websites, or by searching the
contents of websites visited by the cardholder for the competitors'
names, etc.); (5) whether the cardholder searched online for a
different product or service in the same price range as the
transaction amount (e.g., by analyzing search terms and/or results,
and/or by analyzing URLs or contents of websites visited by the
cardholder and comparing prices of products/services, etc.); and/or
(6) whether the cardholder entered search terms indicative of the
cardholder's need for the product or service (e.g., by determining
that the cardholder entered search terms including "pipe leak"
prior to the purchase of new plumbing hardware, or "computer
repair" prior to the purchase of a new hard drive, etc.). In other
embodiments, the interest-based factors 222 may include more, fewer
and/or different factors than those shown in FIG. 4A.
[0116] As is also seen in FIG. 4A, the location-based factors 224
may include: (1) whether the cardholder "checked in" to a flight
having a destination near the location where the transaction was
initiated (e.g., by determining whether the cardholder checked in
to a flight having a destination at the city in which the
transaction occurred, or within a threshold number of miles of the
city in which the transaction occurred, etc.); (2) whether the
cardholder visited a website associated with a place near (or in)
which the transaction was initiated (e.g., by comparing URLs of web
sites visited by the cardholder to URLs of websites known to be
associated with particular areas, and/or by searching the contents
of websites visited by the cardholder for location or area names,
etc.); and/or (3) whether the cardholder endorsed a place near (or
in) which the transaction was initiated via a social media account
of the cardholder (e.g., by determining whether the cardholder
"liked" the geographic area, attraction or other place via his or
her Facebook.RTM. account, etc.). In other embodiments, the
location-based factors 224 may include more, fewer and/or different
factors than those shown in FIG. 4A.
[0117] Generally, the data indicative of whether the circumstance
corresponding to each of interest-based factors 222 and/or
location-based factors 224 is present/true for a particular
cardholder may be included in the first customer online activity
data 110 described above in connection with FIG. 3A. For example,
external data collection unit 42 of FIG. 1 may obtain the search
terms, URLs, user online selections, etc., needed to determine
whether the various factors exist, from the cardholder's computing
device (e.g., one of cardholder computing devices 20) and/or from
an ISP of other sources 24.
[0118] As is also seen in FIG. 4A, each of the interest-based
factors 222 and location-based factors 224 may be associated with a
particular score or weighting value. In the rule set 220 shown in
FIG. 4A, a total score may be calculated based upon which factors
are, or are not, present (e.g., add 94 points if it is determined
that the cardholder searched for the particular lawnmower model
that was purchased, add another 80 points if the transaction was a
"card present" transaction in the Chicago suburb of Joliet and the
cardholder checked in to a flight to Chicago just prior to the
transaction, etc.).
[0119] In some embodiments, certain factors may instead be
associated with negative scores (e.g., minus 80 if the cardholder
checked in to a flight with a destination at least 200 miles from
the site of the transaction and within one day of the transaction,
etc.). Moreover, certain factors may be associated with metrics or
algorithms that determine how heavily those factors are weighed. As
indicated in FIG. 4A, for example, search terms entered by the
cardholder may be used to calculate a "need score" X (e.g., where X
is based upon frequency of certain search terms being used, the
amount of time spent clicking through search results, the magnitude
and/or urgency of a problem indicated by the search terms, etc.),
with X then being used to calculate a score equal to 0.2X.
[0120] The rule set 220 may then output the total score (e.g.,
94+80=+174), a normalized total score, an indication of whether the
total score exceeded a threshold (e.g., a threshold of +100), a
probability calculated based upon the total score, and/or some
other indicator or measure of the existence or likelihood of fraud.
In the example shown in FIG. 4A, it can be seen that larger scores
generally correspond to a greater probability that the transaction
was made or authorized by the cardholder. If the transaction is
being automatically reviewed (e.g., to determine whether a fraud
alert is appropriate, without any initial input from the
cardholder), this may mean that a lower score corresponds to a
higher probability of fraud. Conversely, if the cardholder had
reported the transaction as being fraudulent, a higher score may
correspond to a higher probability of fraud (i.e., fraud on the
part of the cardholder).
[0121] In some embodiments, the rule set 220 may also include one
or more other types of factors not necessarily based upon online
activities of the cardholder (e.g., whether GPS of the cardholder's
smartphone or vehicle indicates that he or she was in that area
shortly before or after the transaction, etc.), and/or may omit
either interest-based factors 222 or location-based factors
224.
B. Exemplary Chargeback Candidate Detection Rule Set
[0122] Referring next to FIG. 4B, an exemplary rule set 230 (e.g.,
generated at process stage 124 of FIG. 3B) may use various factors
relating to a transaction between a cardholder and a merchant to
determine whether the transaction should be flagged as a candidate
for a chargeback (e.g., to determine whether the transaction should
be reviewed under a full set of chargeback rules associated with
the appropriate card network entity). The rule set 230 may
correspond to a particular embodiment and scenario in which the
transaction at issue is a "card present" transaction.
[0123] As seen in FIG. 4B, the factors considered under the rule
set 230 may include: (1) whether an EMV chip card was not inserted
in a point-of-sale EMV chip reader device of the merchant; (2)
whether a non-EMV card was not swiped in a point-of-sale device of
the merchant; (3) whether the card is past its expiration date; (4)
whether the transaction is for the same amount and/or date as
another transaction involving the same card and merchant (e.g., by
analyzing other transactions involving the same account and
merchant within a particular time span); and/or (2) whether the
transaction is for greater than a threshold amount. For example,
one of merchant computing systems 22 of FIG. 1 (or an
acquiring/merchant bank) may provide transaction details that
include the amounts, dates, etc., to FAMS 14 for storage in account
records database 30, and external data collection unit 42 may then
retrieve that information from account records database 30.
Generally, the data indicative of whether the circumstance
corresponding to each of the factors is present/true for a
particular transaction may be included in the first account
transaction data 130 described above in connection with FIG. 3B. In
other embodiments, the factors considered under rule set 230 may
include more, fewer and/or different factors than those shown in
FIG. 4B. It is noted that, in some embodiments, one or more factors
may simply relate to the desirability (e.g., from a card issuer
perspective) of further reviewing whether a chargeback is
appropriate, without necessarily relating to the likelihood that a
chargeback is appropriate.
[0124] As is also seen in FIG. 4B, each of the factors may be
associated with a particular score or weighting value. A total
score may be calculated based upon which factors are, or are not,
present (e.g., add 62 points if it is determined that the
transaction has the same amount and date as another transaction
occurring close in time and involving the same card and merchant).
In some embodiments, certain factors may instead be associated with
negative scores, and/or certain factors may be associated with
metrics or algorithms that determine how heavily those factors are
weighed.
[0125] The rule set 230 may then output the total score, a
normalized total score, an indication of whether the total score
exceeded a threshold, a probability calculated based upon the total
score, and/or some other indicator or measure of the likelihood
that a chargeback is appropriate for the transaction. In the
example shown in FIG. 4B, it can be seen that larger scores
generally correspond to a greater probability that a chargeback is
appropriate.
C. Exemplary Fraud Classification Rule Set
[0126] Referring now to FIG. 4C, an exemplary rule set 240 (e.g.,
generated at process stage 144 of FIG. 3C) may use a diverse array
of factors to classify the type(s) of fraudulent activity, if any,
that is/are suspected to be associated with an event or series of
events. The rule set 240 may correspond to a particular embodiment
and scenario in which the event at issue is a financial transaction
involving a debit or credit card. In other embodiments and/or
scenarios, however, the rule set 240 may classify fraudulent
activity with respect to specific other types of events (e.g., loan
applications), or may detect a variety of different event types
(e.g., various types of financial transactions, loan or credit
applications, etc.) and broadly classify fraudulent activity in
connection with the detected event types (e.g., lost/stolen card
use, application fraud, etc.).
[0127] In one embodiment, each potential classification (with the
possible exception of "no fraud") may be associated with a number
of factors probative of whether that type/class of fraud has
occurred. As seen in FIG. 4C, for example, the rule set 240 may
include counterfeit factors 242 (e.g., factors indicating that a
counterfeit card was used for the transaction), account takeover
factors 244 (e.g., factors indicating that the transaction resulted
from an unauthorized person gaining online access to the credit or
debit card account itself, via phishing, malware or other means),
chargeback fraud factors 246 (e.g., factors indicating that the
cardholder made or otherwise authorized a purchase that the
cardholder later contested) and skimming factors 248 (e.g., factors
indicating that the card information used for the transaction was
obtained via a skimming card reader device illegally installed in
an ATM, gas station pump or other location). In other embodiments,
the rule set 240 may also, or instead, include factors
corresponding to one or more other fraud classifications (e.g.,
forgery, lost/stolen card use, etc.).
[0128] As seen in FIG. 4C, the counterfeit factors 242 may include:
(1) whether the suspect transaction and another, contemporaneous
transaction (e.g., occurring within one hour, etc.) in another
state are both "card present" transactions; and/or (2) if the
suspect transaction is a "card present" transaction, whether the
card (if an EMV chip card) was not inserted in an EMV chip card
reader. For example, one or more of merchant computing systems 22
of FIG. 1 (or one or more acquiring/merchant banks) may provide
transaction details that include whether the transaction was "card
present," whether the card was inserted in an EMV chip card reader,
etc., to FAMS 14 for storage in account records database 30, and
external data collection unit 42 may then retrieve that information
from account records database 30. In other embodiments, the
counterfeit factors 242 may include more, fewer and/or different
factors than those shown in FIG. 4C.
[0129] The account takeover factors 244 may include: (1) whether
the debit or credit card account password was changed within the 10
days prior to the transaction; and/or (2) whether the transaction
was originated from an IP address not associated with the
cardholder. For example, external data collection unit 42 may
retrieve password change information from account records database
30 of FIG. 1, which may log all password update activity, and/or
may retrieve IP address information from one of merchant computing
systems 22 (e.g., the computing system of the merchant involved in
the transaction). In other embodiments, the account takeover
factors 244 may include more, fewer and/or different factors than
those shown in FIG. 4C.
[0130] The chargeback fraud factors 246 may include: (1) whether
the cardholder had searched online for the product or service
purchased via the transaction; and/or (2) whether the cardholder
had visited a website associated with the merchant involved in the
transaction. For example, external data collection unit 42 of FIG.
1 may retrieve online search information (e.g., search terms and/or
results) and/or URLs from the one of cardholder computing devices
20 that is associated with the cardholder, and/or from an ISP (of
other sources 24) used by the cardholder. In other embodiments, the
chargeback fraud factors 246 may include more, fewer and/or
different factors than those shown in FIG. 4C.
[0131] The skimming factors 248 may include: (1) the number (X) of
earlier transactions in which the card used for the transaction at
issue was used at an ATM machine or a gas station pump within the
10 days prior to the transaction at issue; and/or (2) whether the
transaction at issue originated from an IP address not associated
with the cardholder. For example, external data collection unit 42
of FIG. 1 may retrieve transaction data indicating that certain
past purchases were made using gas station pump card readers,
and/or indicating that the card was used for one or more ATM
withdrawals, from account records database 30, and/or may retrieve
the originating IP address from the one of merchant computing
systems 22 associated with the merchant involved in the transaction
at issue. In other embodiments, the skimming factors 248 may
include more, fewer and/or different factors than those shown in
FIG. 4C.
[0132] Generally, the data indicative of whether the circumstance
corresponding to each of counterfeit factors 242, account takeover
factors 244, chargeback fraud factors 246 and/or skimming factors
248 is present/true for a particular transaction may be included in
the first account data 150 described above in connection with FIG.
3C, for example.
[0133] As is also seen in FIG. 4C, each of the counterfeit factors
242, account takeover factors 244, chargeback fraud factors 246 and
skimming factors 248 may be associated with a particular score or
weighting value. The factors for each classification (counterfeit,
account takeover, chargeback fraud, skimming) may be used to
calculate a total score specific to that classification. In the
rule set 240 shown in FIG. 4C, for example, a counterfeit score may
be calculated based upon which of factors 242 are, or are not,
present, an account takeover score may be calculated based upon
which of factors 244 are, or are not, present, and so on. In some
embodiments, certain factors may instead be associated with
negative scores, and/or certain factors (e.g., the first of
skimming factors 248 shown in FIG. 4C) may be associated with
metrics or algorithms that determine how heavily those factors are
weighed.
[0134] For each classification/category, the rule set 240 may
output the total score, a normalized total score, an indication of
whether the total score exceeded a threshold, a probability
calculated based upon the total score, and/or some other indicator
or measure of the likelihood that fraud of that particular
type/class occurred in connection with the transaction. In the
example shown in FIG. 4C, it can be seen that larger scores
generally correspond to a greater probability that the respective
classification is accurate. Referring back to FIG. 3C, the
classification at process stage 152 may be the classification
having the highest score and/or probability under rule set 240, or
may include the score and/or probability for each classification,
the top three classifications, etc.
D. Exemplary Application Fraud Detection Rule Set
[0135] Referring now to FIG. 4D, an exemplary rule set 260 may use
online search information (e.g., search terms, search results,
clicked/selected search results, etc.) to detect whether an
application was fraudulent (e.g., not populated and/or submitted by
the purported applicant). The rule set 260 may have been generated
at process stage 164 of FIG. 3D, for example. The rule set 260 may
be incorporated into a review process that is generally applied to
all applications received by a particular entity or anti-fraud
service, or a review process applied only to those applications
that were flagged by a preliminary fraud alert, for example.
[0136] The factors considered under the rule set 260 may generally
be probative of whether the person that submitted the application
(e.g., via a web browser, a dedicated application, as an email
attachment, by snail mail, etc.) had performed one or more online
searches indicating that he or she was trying to learn more about
the purported applicant in order to populate particular fields of
the application (e.g., a "home address" field, "employment history"
fields, etc.). The "purported applicant" may be a person whose name
appears in a name and/or signature field of the application, for
example.
[0137] As seen in FIG. 4D, the factors of exemplary rule set 260
may include: (1) whether the applicant used search terms that
included the name of the purported applicant; (2) whether the
search terms also included the words "address" or "residence" (and
possibly other synonyms or near-synonyms); and/or (3) whether the
search terms also included the words "employer," "job" and/or
"career" (and possibly other synonyms or near-synonyms). In other
embodiments, the rule set 260 may include more, fewer and/or
different factors than those shown in FIG. 4D. For example, the
rule set 260 may include one or more factors relating to which
search results appeared and/or were selected (e.g., "clicked" on
after appearing on a user interface) by the applicant.
[0138] Generally, the data indicative of whether the circumstances
corresponding to the factors of rule set 260 are present/true for a
particular applicant may be included in the first applicant search
history data 170 described above in connection with FIG. 3D. For
example, external data collection unit 42 of FIG. 1 may obtain the
search terms, search results, search result user selections, etc.,
needed to determine whether the various factors exist, from the
applicant's computing device (e.g., similar to one of cardholder
computing devices 20) and/or from an ISP of other sources 24.
Access to such information may be made a condition of having the
application be considered, for example.
[0139] As is also seen in FIG. 4D, each of the factors of rule set
260 may be associated with a particular score or weighting value. A
total score may then be calculated based upon which factors are, or
are not, present. In some embodiments, certain factors may instead
be associated with negative scores, and/or certain factors may be
associated with metrics or algorithms that determine how heavily
those factors are weighed.
[0140] The rule set 260 may then output the total score, a
normalized total score, an indication of whether the total score
exceeded a threshold, a probability calculated based upon the total
score, and/or some other indicator or measure of the existence or
likelihood of application fraud. In the example shown in FIG. 4D,
it can be seen that larger scores may generally correspond to a
greater probability that the application was not populated and/or
submitted by the purported applicant.
E. Exemplary Fraud Dispute Resolution Rule Set
[0141] Referring now to FIG. 4E, a flow diagram illustrates at
least a portion of a process flow 270 implementing an exemplary
rule set for fraud dispute, or potential fraud dispute, resolution
(e.g., a rule set generated at process stage 184 of FIG. 3E). The
process flow 270 may be used to help resolve a dispute over a
contested transaction, or to help a customer recall an unrecognized
transaction, for example. FIG. 4E illustrates a process flow,
rather than just a set of factors, in order to better illustrate an
example process for generating queries based upon the generated
rules, according to one embodiment. The process flow 270 may
correspond to a particular embodiment and scenario in which the
transaction subject to dispute or potential dispute is a credit or
debit card transaction.
[0142] In the exemplary process flow 270, the rule set may specify
that a process stage 272 determines whether the transaction was a
"card present" transaction. If not, the rule set may specify that
the flow proceed directly to a process stage 280. If so, however,
the rule set may specify that the flow instead proceeds to a
process stage 274.
[0143] The rule set may also specify that process stage 274
determines whether at least one other transaction associated with
the cardholder's account occurred within some threshold number of
hours (X) of the transaction at issue. If not, the rule set may
specify that the flow proceeds directly to process stage 280. If
so, however, the rule set may specify that the flow instead
proceeds to a process stage 276.
[0144] Process stage 276 may generate one or more location-related
queries using transaction data associated with the cardholder's
account. The queries may ask, for example, whether the cardholder
was in (or near) one or more particular geographic areas or
locations at various times. If the transaction at issue occurred in
San Francisco, for example, with a first other "card present"
transaction occurring in Santa Rosa four hours earlier and a second
other "card present" transaction occurring in San Jose two hours
later, process stage 276 may generate one or more queries asking
whether the cardholder made or authorized the earlier and/or later
transactions, and/or whether the cardholder traveled on a route
from Santa Rosa to San Jose that passed through San Francisco,
etc.
[0145] In some embodiments, the location-related queries are
generated based upon data associated with events or circumstances
other than transactions. For example, if the transaction at issue
occurred in Sarasota, Fla., and the data considered under the rule
set indicates that the cardholder checked in to a flight to Tampa,
process stage 276 may generate one or more queries asking whether
the cardholder completed the flight, where the cardholder went
after landing in Tampa, etc.
[0146] The rule set may also specify that process stage 280
determines whether the transaction at issue is associated with a
billing alias that is dissimilar to the name of the merchant
involved in the transaction. For example, the computing system of
the merchant (e.g., one of merchant computing systems 22 of FIG. 1)
may have sent to FAMS 14 a transaction record that identified the
merchant by the alias, and was presented to the cardholder as an
online or paper account statement. The determination at process
stage 280 may use the billing alias to identify a legal and/or
common name of the merchant (e.g., using a relational database
stored in AFSS 12 or FAMS 14), and determine that there is at least
some threshold level of dissimilarity (e.g., based upon difference
of characters, character ordering, etc.) between the billing alias
and the merchant name.
[0147] If the billing alias and merchant name are not sufficiently
dissimilar, the rule set may specify that the flow proceeds
directly to a process stage 284. If sufficiently dissimilar,
however, the rule set may specify that the flow instead proceeds to
a process stage 282. Process stage 282 may generate a query
relating to the billing alias that was presented to the cardholder.
For example, the query may ask whether the cardholder is aware that
the billing alias is used by that particular merchant. In some
embodiments, process stage 282 may instead generate a message that
simply informs the cardholder that the billing alias corresponds to
the merchant, without posing a question.
[0148] The rule set may specify that process stage 284 generates
one or more default queries. For example, one default query may ask
whether the cardholder lent his or her card to a friend or family
member around the time of the transaction. In some embodiments
and/or scenarios, process stage 284 may be omitted from process
flow 270. Generally, the queries (and possibly non-query messages)
generated in process flow 270 may serve to help the cardholder
recall whether the transaction was made or authorized, and/or
process flow 270 may prompt the cardholder for responses that are
considered by others (e.g., personnel of an entity associated with
FAMS 14 of FIG. 1) to determine whether the transaction was likely
fraudulent.
[0149] Although not shown in FIG. 4E, in some embodiments process
flow 270 may include a number of iterative stages in which
responses are received from the cardholder (e.g., from the
respective one of cardholder computing devices 20 in FIG. 1) and
used to generate additional, more detailed questions for the
cardholder. For example, if a first query asks whether the
cardholder recalls personally making another "card present"
transaction that occurred at a nearby time and place, and the
cardholder responds "no," a new query may be generated asking
whether the cardholder recalls personally making the next closest
transaction (in terms of time and/or location).
F. Exemplary Document Fraud Detection Rule Set
[0150] Referring next to FIG. 4F, an exemplary rule set 290 (e.g.,
generated at process stage 204 of FIG. 3F) may use various factors
relating to an imaged (e.g., photographed or scanned) physical
document to determine whether the document should be flagged as a
candidate for a more in-depth (e.g., manual) analysis/review for
fraud purposes. The rule set 290 may correspond to a particular
embodiment and scenario in which the document is one that includes
at least a signature field (e.g., a personal check, a driver's
license, etc.).
[0151] The factors considered under the rule set 290 may include a
number of counterfeit factors 292 and a number of forgery factors
294, each of which may be evaluated by image analysis unit 52 of
FIG. 1 using one or more image processing techniques. The
counterfeit factors 292 may relate to the look, presentation,
format and/or structure of the document, while the forgery factors
294 may relate to the substance, style or format of information
entered in one or more fields of the document.
[0152] As seen in FIG. 4F, the counterfeit factors 292 may include:
(1) whether one or more absolute or relative dimensions and/or
angles of the document, or of lines, illustrations, patterns, etc.
shown on the document (excluding user-entered contents in fields
such as the signature line), are outside one or more predetermined
tolerances; (2) whether one or more colors on the document are
outside a predetermined tolerance (e.g., color/frequency range);
(3) whether one or more line thicknesses of the document (excluding
user-entered field contents) are outside one or more predetermined
tolerances; and/or (4) whether one or more fonts on the document
(excluding user-entered field contents) are outside one or more
predetermined tolerances. For example, image analysis unit 52 may
determine whether the ratio of the document length to the document
width is within 0.1% of an expected value. As another example,
image analysis unit 52 may determine whether horizontal and
vertical lines on the document are within 0.3 degrees of the
horizontal and vertical edges of the document, respectively. As yet
another example, image analysis unit 52 may determine whether a
font used for a field descriptor or other text on the document
matches an expected font (e.g., by meeting a similarity threshold
measured in any suitable manner). In other embodiments, the
counterfeit factors 292 may include more, fewer and/or different
factors than those shown in FIG. 4F.
[0153] The forgery factors 294 may include: (1) whether a signature
entered in a signature field of the document match is outside a
predetermined tolerance (e.g., using any suitable signature
recognition technique); (2) whether handwriting entered in one or
more fields of the document is outside a predetermined tolerance
(e.g., by applying a suitable handwriting recognition technique);
and/or (3) whether the format of information entered by a user in
one or more fields does not match an expected format (e.g., using
"9.12.16" rather than the expected "9/12/2016," as established
based upon other documents known to have been populated and/or
submitted by the purported applicant). In other embodiments, the
forgery factors 294 may include more, fewer and/or different
factors than those shown in FIG. 4F.
[0154] Generally, the data indicative of whether the circumstances
corresponding to counterfeit factors 292 and/or forgery factors 294
are present/true for a particular document may be included in the
first document image data 210 described above in connection with
FIG. 3F.
[0155] As is also seen in FIG. 4F, each of the counterfeit factors
292 and forgery factors 294 may be associated with a particular
score or weighting value. In the rule set 290 shown in FIG. 4F, a
total score may be calculated based upon which factors are, or are
not, present. In some embodiments, certain factors may instead be
associated with negative scores, and/or certain factors may be
associated with metrics or algorithms that determine how heavily
those factors are weighed.
[0156] The rule set 290 may then output the total score, a
normalized total score, an indication of whether the total score
exceeded a threshold, a probability calculated based upon the total
score, and/or some other indicator or measure of the likelihood
that the document is fraudulent. Alternatively, the rule set 290
may output a separate total score, normalized score, probability,
or other metric, for each of counterfeit factors 292 and forgery
factors 294, with the counterfeit metric indicating the likelihood
that the document is a counterfeit and the forgery metric
indicating the likelihood that the document was fraudulently
populated by someone other than the purported person (e.g., by
someone other than the person corresponding to the name, signature,
address, etc. on the document). In the example shown in FIG. 4F, it
can be seen that larger scores generally correspond to a greater
probability that the document is fraudulent. In some embodiments,
the rule set 290 also includes one or more other types of factors
not shown in FIG. 4F, and/or omits either counterfeit factors 292
or forgery factors 294.
V. Exemplary Methods for Fraud Detection & Classification
[0157] FIGS. 5-7 depict flow diagrams of various exemplary
computer-implemented methods that may be implemented by one or more
components of AFSS 12 of FIG. 1. In one embodiment, AFSS 12
implements all of the methods corresponding to FIGS. 5-7. In other
embodiments, AFSS 12 implements only a subset (e.g., one, two,
etc.) of the methods corresponding to FIGS. 5-7. Each of the
methods described below may be implemented by fraud
detection/classification unit 36 of FIG. 1, for example.
A. Exemplary Methods for Facilitating Document-Related Fraud
Detection
[0158] Referring now to FIG. 5, an exemplary computer-implemented
method 300 may be used to facilitate the detection of
document-related fraud, e.g., by winnowing the field of documents
needing a more thorough (e.g., manual) review or investigation. In
the method 300, fraudulent document detection rules may be
generated or updated at least by training a machine learning
program (block 302), such as any of the types of machine learning
programs discussed above in connection with ML rule generator 40 of
FIG. 1 or process stage 84 of FIG. 2, for example. The machine
learning program may be trained using image data corresponding to a
plurality of physical documents, and fraud determinations/labels
each corresponding to a respective one of those documents.
[0159] The physical documents and the fraudulent document detection
rules may correspond to a first type of document, which may be a
fairly general type (e.g., a personal check or other general type
of financial instrument, or a driver's license or other general
type of identification document, etc.), or a more specific type
(e.g., a personal check associated with a particular bank, or a
driver's license from a particular state, etc.).
[0160] The rules generated or updated at block 302 may specify, for
example, an acceptable tolerance for an absolute or relative
measurement pertaining to a document (e.g., ratio of overall length
to width, of various decorative or functional features depicted on
the document, etc.). As other examples, the rules may specify an
acceptable font or set of fonts, an acceptable pattern or set of
patterns, an acceptable color or set (e.g., range) of colors, and
so on. As yet another example, the rules may specify one or more
acceptable field locations (e.g., placement of a signature line
within the document, etc.).
[0161] First image data corresponding to an image of a first
physical document may be received (block 304). The first physical
document may be of the same specific or general type as the
documents used to train the machine learning program at block 302
(e.g., a personal check, or a personal check associated with a
particular bank, etc.). In some embodiments where fraud, or
potential fraud, is detected substantially in real-time, the first
image data is received from a point-of-sale computing device
associated with a merchant. For example, the merchant may, during
or before a transaction, scan or photograph an identification card
of a customer, and the point-of-sale computing device (or another
computing device of the merchant) may send the image of the
identification card to a server implementing the method 300.
[0162] It may be determined, by applying the fraudulent document
detection rules to the first image data, that the first physical
document is, or may be (e.g., according to some probability level),
fraudulent (block 306). For example, the first physical document
may be flagged as requiring a more in-depth review of its
authenticity. In other scenarios, not represented by FIG. 5, it may
instead be determined that the first physical document is not, or
likely is not, fraudulent, (e.g., such that it is not necessary to
flag the application for further review). In one embodiment, block
306 may occur substantially in real-time upon receiving the first
image data (e.g., from a merchant point-of-sale device).
[0163] An indication of whether the first physical document is, or
may be, fraudulent may be caused to be displayed to one or more
people via one or more respective computing device user interfaces
(block 308). The indication may also specify additional
information, such as a reason why the document is suspect (e.g.,
the document is or may be counterfeit, and/or the contents in one
or more fields of the document have been or may have been forged,
etc.). The indication may be sent to a point-of-sale computing
device of a merchant that provided the first image data, for
example, to cause the device to display the indication to the
merchant or an employee of the merchant. Alternatively, or in
addition, the indication may be provided to a computing device of a
card issuer or other entity (e.g., to AFSS 12 of FIG. 1) to prompt
a full review of the document (e.g., a manual investigation). In
one embodiment, block 308 may occur substantially in real-time upon
receiving the first image data. Block 308 may be implemented by
notification unit 56 of FIG. 1, for example.
[0164] In some embodiments, the method 300 may include one or more
additional blocks not shown in FIG. 5. For example, the method 300
may include an additional block in which it is determined that the
first physical document corresponds to the same type as the
documents used to train the machine learning program at block 302
(e.g., by using image processing to recognize various document
features, such as locations and/or types of different fields in the
document, etc.). In one embodiment, block 306 occurs in response to
such a determination.
[0165] FIG. 6 illustrates a computer-implemented method 320 of
identifying fraudulent transactions, or financial instruments or
identification cards. The method 320 may include, via one or more
processors and/or transceivers (via wireless communication or data
transmission over one or more radio frequency links or wireless
communication channels), (1) receiving a digital image of a signed
financial instrument or identification card (block 322); (2)
analyzing the digital image using optical character recognition or
other techniques to identify (i) a type of financial instrument or
identification card; and (ii) an originating entity of the
financial instrument or identification card (block 324); (3)
determine the expected fields of the financial instrument or
identification card based upon the (i) type, and (ii) originating
entity, and/or allowable content, or an allowable range of content
or characters (letters, numbers, etc.), for the expected field
(block 326); (4) analyzing the digital image using optical
character recognition or other techniques to identify actual fields
on the financial instrument or identification card (block 328); (5)
determining if the expected fields match the actual fields on the
financial instrument or identification card to determine if a
fraudulent field exists on the financial instrument or
identification card (block 330); and/or (6) if a fraudulent field
exists, then halting the transaction, and/or generating and
transmitting an electronic notification detailing that a fraudulent
or unexpected field exists (block 332).
[0166] The method 320 may also include, (7) if a fraudulent field
does not exist, then analyzing the digital image using optical
character recognition or other techniques to identify actual
characters or content within the actual fields on the financial
instrument or identification card (block 334); (8) comparing the
actual characters or content within the actual fields with the
allowable content, or the allowable range of content or characters,
for the corresponding expected field to determine if fraudulent
characters or content are in an expected field (block 336); and/or
(9) if fraudulent content in an expected field exists, generating
an electronic notification detailing the fraud or a why the
financial instrument or identification card is suspicious, and/or
transmitting the electronic notification to a computing device of a
financial institution at which the financial instrument or
identification card is being presented (block 338) to facilitate
halting a transaction, flagging a financial instrument or
identification card for further review, and/or identifying and
reducing fraud.
[0167] In one embodiment, a computer-implemented method of
identifying fraudulent transactions, or financial instruments or
identification cards may be provided. The method may include (1)
receiving, via one or more processors and/or transceivers, a
digital image of a signed financial instrument or identification
card from a financial institution or merchant computing terminal,
such as via wireless communication or data transmission over one or
more radio links or wireless communication channels; (2) analyzing,
via the one or more processors, the digital image using optical
character recognition or other techniques to identify (i) a type of
financial instrument or identification card; and (ii) an
originating entity of the financial instrument or identification
card; (3) determine, via the one or more processors, the expected
fields of the financial instrument or identification card based
upon the (i) type, and (ii) originating entity; (4) analyzing, via
the one or more processors, the digital image using optical
character recognition (OCR) or other techniques to identify actual
fields on the financial instrument or identification card; (5)
determining, via the one or more processors, if the expected fields
match the actual fields on the financial instrument or
identification card to determine if a fraudulent field exists on
the financial instrument or identification card (for instance, an
actual field may not match a size, height, or width of an expected
field, or an actual field may be at an angle or slant, as compared
to perfectly horizontal); (6) if a fraudulent field does exist,
then generating, via the one or more processors, an electronic
notification indicating that a fraudulent field exists; and/or (7)
transmitting, via the one or more processors and/or transceivers,
the electronic notification to the merchant computing terminal to
provide notice of the fraudulent field.
[0168] The method may further include if a fraudulent field does
not exist, then (i) determining or retrieving, allowable content,
or an allowable range of content or characters, for the expected
fields; (ii) analyzing, via the one or more processors, the digital
image using optical character recognition or other techniques to
identify actual characters or content within the actual fields on
the financial instrument or identification card; (iii) comparing,
via the one or more processors, the actual characters or content
within an actual field with the allowable content, or the allowable
range of content or characters, for the corresponding expected
field to determine if fraudulent characters or content are in an
expected field (for instance, the font or size of characters,
letters, or number be incorrect, such as too large or too small in
font size, or color of characters may be incorrect); (iv) if
fraudulent content in an expected field exists, generating, via the
one or more processors, an electronic notification detailing the
fraud or a why the financial instrument or identification card is
suspicious; and/or (v) transmitting, via the one or more processors
and/or transceivers, the electronic notification to a computing
device of a financial institution or merchant at which the
financial instrument or identification card is being presented to
facilitate halting a transaction, and/or identifying and reducing
fraud.
[0169] The identification card may be a social security card, and
an expected field may be associated with a location of where a
social security number is printed, and the allowable content may be
9 numbers that comprise a social security number. The financial
instrument may be a personal check, and an expected field may be
associated with a location of where a bank routing number is
printed, and the allowable content may be a bank routing number.
Additionally or alternatively, the financial instrument may be a
personal check, and an expected field may be associated with a
location of where a checking account is printed, and the allowable
content may be a checking account number.
[0170] The identification card may be a driver's license, and an
expected field may be associated with a location of where a driver
license number is printed, and the allowable content may be a
driver's license number. Additionally or alternatively, the
identification card may be a passport, and expected fields may be
associated with a name, date of birth, and expiration date, and the
allowable content may include characters or letters for a name
field, and numbers for the date of birth and expiration date
fields. The identification card may be a social security card, and
the allowable content may be a range of possible social security
numbers available to an individual based upon a location and date
of their birth.
[0171] In one embodiment, a computer system configured to identify
fraudulent transactions, or financial instruments or identification
cards may be provided. The computer system may include one or more
processors and/or transceivers configured to: (1) receive, via
wireless communication or data transmission over one or more radio
links or wireless communication channels, a digital image of a
signed financial instrument or identification card from a financial
institution or merchant computing terminal; (2) analyze the digital
image using optical character recognition or other techniques to
identify (i) a type of financial instrument or identification card;
and (ii) an originating entity of the financial instrument or
identification card; (3) determine the expected fields of the
financial instrument or identification card based upon the (i)
type, and (ii) originating entity; (4) analyze the digital image
using optical character recognition or other techniques to identify
actual fields on the financial instrument or identification card;
(5) determine if the expected fields match the actual fields on the
financial instrument or identification card to determine if a
fraudulent field exists on the financial instrument or
identification card; (6) if a fraudulent field does exist, then
generate an electronic notification indicating that a fraudulent
field exists; and/or (7) transmit, via wireless communication or
data transmission over one or more radio links or wireless
communication channels, the electronic notification to the merchant
computing terminal to provide notice of the fraudulent field.
[0172] The one or more processors and/or transceivers may be
further configured to, if a fraudulent field does not exist, then
determine or retrieve allowable content, or an allowable range of
content or characters (such as size of font or color, and type of
characters, for allowable content), for the expected fields;
analyze the digital image using optical character recognition or
other techniques to identify actual characters or content within
the actual fields on the financial instrument or identification
card; compare the actual characters or content within an actual
field with the allowable content, or the allowable range of content
or characters, for the corresponding expected field to determine if
fraudulent characters or content are in an expected field; if
fraudulent content in an expected field exists (such as letters in
a numeric field, or incorrect font size or color for characters),
generate an electronic notification detailing the fraud or a why
the financial instrument or identification card is suspicious;
and/or transmit, via wireless communication or data transmission
over one or more radio links or wireless communication channels,
the electronic notification to a computing device of a financial
institution or merchant at which the financial instrument or
identification card is being presented to facilitate halting a
transaction, and/or identifying and reducing fraud.
[0173] The identification card may be a passport, and expected
fields may be associated with a name, date of birth, and expiration
date, and the allowable content may include characters or letters
for a name field, and numbers for the date of birth and expiration
date fields. The identification card may be a social security card,
and the allowable content may be a range of possible social
security numbers available to an individual based upon where and
when they were born.
[0174] FIG. 7 illustrates a computer-implemented method 340 of
identifying fraudulent transactions and/or fraudulent signatures on
financial instruments or identification cards. The method 340 may
include, via one or more processors and/or transceivers (such as
via wireless communication or data transmission over one or more
radio frequency links and/or wireless communication channels), (1)
receiving a digital image of a signed financial instrument or
identification card (block 342); (2) analyzing the digital image
using optical character recognition or other techniques to identify
a name printed in font or set typeface on the financial instrument
or identification card (block 344); (3) analyzing the digital image
using optical character recognition or other techniques to identify
a current handwritten signature on the financial instrument or
identification card (block 346); (4) retrieving a past known or
trusted digital signature of person associated with the name
printed in font or set typeface on the financial instrument or
identification card from a local or remote memory, or a third party
database (block 348); (5) comparing the current handwritten
signature with the past known or trusted digital signature to
determine a mismatch, or otherwise inputting the current
handwritten signature and/or trusted digital signature into a
machine learning program trained to identify fraudulent signatures
(block 350); (6) if a mismatch is identified, generating an
electronic notification detailing the fraud or why the signature is
suspicious, and/or transmitting the electronic notification to a
computing device of a financial institution at which the financial
instrument or identification card is being presented (block 352) to
facilitate halting a transaction, and/or identifying and reducing
fraud.
VI. Exemplary System for Fraud Detection & Classification
[0175] FIG. 8 depicts an exemplary computer system 500 in which the
techniques described herein may be implemented, according to one
embodiment. The computer system 500 of FIG. 8 may include a
computing device in the form of a computer 510. Components of the
computer 510 may include, but are not limited to, a processing unit
520, a system memory 530, and a system bus 521 that couples various
system components including the system memory 530 to the processing
unit 520. The system bus 521 may be any of several types of bus
structures including a memory bus or memory controller, a
peripheral bus, or a local bus, and may use any suitable bus
architecture. By way of example, and not limitation, such
architectures include the Industry Standard Architecture (ISA) bus,
Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus,
Video Electronics Standards Association (VESA) local bus, and
Peripheral Component Interconnect (PCI) bus (also known as
Mezzanine bus).
[0176] Computer 510 may include a variety of computer-readable
media. Computer-readable media may be any available media that can
be accessed by computer 510 and may include both volatile and
nonvolatile media, and both removable and non-removable media. By
way of example, and not limitation, computer-readable media may
comprise computer storage media and communication media. Computer
storage media may include 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
may include, but is not limited to, RAM, ROM, EEPROM, FLASH memory
or other memory technology, CD-ROM, digital versatile disks (DVD)
or other optical disk storage, magnetic cassettes, magnetic tape,
magnetic disk storage or other magnetic storage devices, or any
other medium which can be used to store the desired information and
which can accessed by computer 510.
[0177] 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 may include any information delivery media. The term
"modulated data signal" means a signal that has one or more of its
characteristics set or changed in such a manner as to encode
information in the signal. By way of example, and not limitation,
communication media may include wired media such as a wired network
or direct-wired connection, and wireless media such as acoustic,
radio frequency (RF), infrared and other wireless media.
Combinations of any of the above are also included within the scope
of computer-readable media.
[0178] The system memory 530 may include computer storage media in
the form of volatile and/or nonvolatile memory such as read only
memory (ROM) 531 and random access memory (RAM) 532. A basic
input/output system 533 (BIOS), containing the basic routines that
help to transfer information between elements within computer 510,
such as during start-up, is typically stored in ROM 531. RAM 532
typically contains data and/or program modules that are immediately
accessible to, and/or presently being operated on, by processing
unit 520. By way of example, and not limitation, FIG. 8 illustrates
operating system 534, application programs 535, other program
modules 536, and program data 537.
[0179] The computer 510 may also include other
removable/non-removable, volatile/nonvolatile computer storage
media. By way of example only, FIG. 8 illustrates a hard disk drive
541 that reads from or writes to non-removable, nonvolatile
magnetic media, a magnetic disk drive 551 that reads from or writes
to a removable, nonvolatile magnetic disk 552, and an optical disk
drive 555 that reads from or writes to a removable, nonvolatile
optical disk 556 such as a CD ROM or other optical media. Other
removable/non-removable, volatile/nonvolatile computer storage
media that can be used in the exemplary operating environment
include, but are not limited to, magnetic tape cassettes, flash
memory cards, digital versatile disks, digital video tape, solid
state RAM, solid state ROM, and the like. The hard disk drive 541
may be connected to the system bus 521 through a non-removable
memory interface such as interface 540, and magnetic disk drive 551
and optical disk drive 555 may be connected to the system bus 521
by a removable memory interface, such as interface 550.
[0180] The drives and their associated computer storage media
discussed above and illustrated in FIG. 8 provide storage of
computer-readable instructions, data structures, program modules
and other data for the computer 510. In FIG. 8, for example, hard
disk drive 541 is illustrated as storing operating system 544,
application programs 545, other program modules 546, and program
data 547. Note that these components can either be the same as or
different from operating system 534, application programs 535,
other program modules 536, and program data 537. Operating system
544, application programs 545, other program modules 546, and
program data 547 are given different numbers here to illustrate
that, at a minimum, they are different copies. A user may enter
commands and information into the computer 510 through input
devices such as cursor control device 561 (e.g., a mouse,
trackball, touch pad, etc.) and keyboard 562. A monitor 591 or
other type of display device is also connected to the system bus
521 via an interface, such as a video interface 590. In addition to
the monitor, computers may also include other peripheral output
devices such as printer 596, which may be connected through an
output peripheral interface 595.
[0181] The computer 510 may operate in a networked environment
using logical connections to one or more remote computers, such as
a remote computer 580. The remote computer 580 may be a personal
computer, a server, a router, a network PC, a peer device or other
common network node, and may include many or all of the elements
described above relative to the computer 510, although only a
memory storage device 581 has been illustrated in FIG. 8. The
logical connections depicted in FIG. 8 include a local area network
(LAN) 571 and a wide area network (WAN) 573, but may also include
other networks. Such networking environments are commonplace in
hospitals, offices, enterprise-wide computer networks, intranets
and the Internet.
[0182] When used in a LAN networking environment, the computer 510
is connected to the LAN 571 through a network interface or adapter
570. When used in a WAN networking environment, the computer 510
may include a modem 572 or other means for establishing
communications over the WAN 573, such as the Internet. The modem
572, which may be internal or external, may be connected to the
system bus 521 via the input interface 560, or other appropriate
mechanism. The communications connections 570, 572, which allow the
device to communicate with other devices, are an example of
communication media, as discussed above. In a networked
environment, program modules depicted relative to the computer 510,
or portions thereof, may be stored in the remote memory storage
device 581. By way of example, and not limitation, FIG. 8
illustrates remote application programs 585 as residing on memory
device 581.
[0183] The techniques for detecting and/or classifying fraud
described above may be implemented in part or in their entirety
within a computer system such as the computer system 500
illustrated in FIG. 8. The computer 510 may be included in AFSS 12
of FIG. 1, for example, and/or the remote application programs 585
may include one or more applications of either FAMS 14, one of
cardholder computing device 20, one of merchant computing systems
22, or a computing device of other sources 24. Moreover, the
functionality of fraud detection/classification unit 36 of FIG. 1
may be implemented by one or more of application programs 535
and/or other program modules 536. As another example, ML rules
database 58, account holder behaviors database 60 and/or chargeback
rules database 62 of FIG. 1 may be stored in hard disk drive 541
(e.g., as program data 547), magnetic disk 552 and/or optical disk
drive 555, and/or the data retrieved by fraud
detection/classification unit 36 of FIG. 1 may be stored in hard
disk drive 541 (e.g., as program data 547) and/or RAM 532 (e.g., as
program data 537).
VII. Exemplary Method Embodiments
[0184] In another aspect, a computer-implemented method,
implemented in one or more servers or other computing devices, of
facilitating detection of document-related fraud may include (1)
generating or updating, by one or more processors of the one or
more servers, fraudulent document detection rules at least by
training a machine learning program using at least (i) image data
corresponding to a plurality of physical documents, and (ii) fraud
determinations each corresponding to a respective one of the
plurality of physical documents, wherein the plurality of physical
documents and the fraudulent document detection rules may
correspond to a first type of document; (2) receiving, by the one
or more processors, first image data corresponding to an image of a
first physical document, wherein the first physical document may
correspond to the first type of document; (3) determining, by the
one or more processors applying the fraudulent document detection
rules to the first image data, that the first physical document is,
or may be, fraudulent; and/or (4) causing, by the one or more
processors, an indication of whether the first physical document
is, or may be, fraudulent to be displayed to one or more people via
one or more respective computing device user interfaces. The method
may include additional, fewer or alternative actions, such as any
of those discussed elsewhere herein.
[0185] For instance, the method may further include determining, by
the one or more processors, that the first physical document
corresponds to the first type of document, and/or the one or more
processors may apply the fraudulent document detection rules to the
first physical document in response to determining that the first
physical document corresponds to the first type of document.
[0186] Additionally or alternatively, generating fraudulent
document detection rules may include determining an acceptable
tolerance for an absolute or relative measurement.
[0187] Additionally or alternatively, generating fraudulent
document detection rules may include determining (i) an acceptable
font or set of fonts, (ii) an acceptable pattern or set of
patterns, and/or (iii) an acceptable color or set of colors.
[0188] Additionally or alternatively, generating fraudulent
document detection rules may include determining an acceptable
field location. Additionally or alternatively, the first type of
document may be a financial instrument or an identification
card.
[0189] Additionally or alternatively, both (i) determining that the
first physical document is, or may be, fraudulent, and (ii) causing
the indication of whether the first physical document is, or may
be, fraudulent to be displayed, may occur substantially in
real-time upon receiving the first image data. Additionally or
alternatively, causing the indication of whether the first physical
document is, or may be, fraudulent to be displayed may include
causing a point-of-sale computing device associated with a merchant
to display the indication.
VIII. Exemplary System Embodiments
[0190] In another aspect, a computer system for facilitating
detection of document-related fraud may include (1) a rules
database configured to store fraudulent document detection rules;
(2) one or more processors; and/or (3) a non-transitory memory. The
non-transitory memory stores instructions that, when executed by
the one or more processors, may cause the one or more processors to
(1) generate or update the fraudulent document detection rules at
least by training a machine learning program using at least (i)
image data corresponding to a plurality of physical documents, and
(ii) fraud determinations each corresponding to a respective one of
the plurality of physical documents, wherein the plurality of
physical documents and the fraudulent document detection rules may
correspond to a first type of document; (2) receive first image
data corresponding to an image of a first physical document,
wherein the first physical document may correspond to the first
type of document; (3) determine, by applying the fraudulent
document detection rules stored in the rules database to the first
image data, that the first physical document is, or may be,
fraudulent; and/or (4) cause an indication of whether the first
physical document is, or may be, fraudulent to be displayed to one
or more people via one or more respective computing device user
interfaces. The system may include additional, fewer or alternative
components, features and/or functionality, such as any of those
discussed elsewhere herein.
[0191] For instance, the instructions may further cause the one or
more processors to determine that the first physical document
corresponds to the first type of document, and/or the instructions
may cause the one or more processors to apply the fraudulent
document detection rules to the first physical document in response
to determining that the first physical document corresponds to the
first type of document. Additionally or alternatively, the
fraudulent document detection rules may specify an acceptable
tolerance for an absolute or relative measurement. Additionally or
alternatively, the fraudulent document detection rules may specify
(i) an acceptable font or set of fonts, (ii) an acceptable pattern
or set of patterns, and/or (iii) an acceptable color or set of
colors. Additionally or alternatively, the fraudulent document
detection rules may specify an acceptable field location.
[0192] Additionally or alternatively, the first type of document
may be a financial instrument or an identification card.
Additionally or alternatively, the instructions may cause the one
or more processors to both (i) determine that the first physical
document is, or may be, fraudulent, and (ii) cause the indication
of whether the first physical document is, or may be, fraudulent to
be displayed, substantially in real-time upon receiving the first
image data.
IX. Exemplary Computer-Readable Medium Embodiments
[0193] In another aspect, a non-transitory, computer-readable
medium stores instructions that, when executed by one or more
processors, may cause the one or more processors to (1) generate or
update fraudulent document detection rules at least by training a
machine learning program using at least (i) image data
corresponding to a plurality of physical documents, and (ii) fraud
determinations each corresponding to a respective one of the
plurality of physical documents, wherein the plurality of physical
documents and the fraudulent document detection rules may
correspond to a first type of document; (2) receive first image
data corresponding to an image of a first physical document, the
first physical document corresponding to the first type of
document; (3) determine, by applying the fraudulent document
detection rules to the first physical document, that the first
physical document is, or may be, fraudulent; and/or (4) cause an
indication of whether the first physical document is, or may be,
fraudulent to be displayed to one or more people via one or more
respective computing device user interfaces. The computer-readable
medium may store instructions that include additional, fewer or
alternative actions, such as any of those discussed elsewhere
herein.
[0194] For instance, the instructions may further cause the one or
more processors to determine that the first physical document
corresponds to the first type of document, and/or the instructions
cause the one or more processors to apply the fraudulent document
detection rules to the first physical document in response to
determining that the first physical document corresponds to the
first type of document. Additionally or alternatively, the
fraudulent document detection rules may specify an acceptable
tolerance for an absolute or relative measurement. Additionally or
alternatively, the fraudulent document detection rules may specify
(i) an acceptable font or set of fonts, (ii) an acceptable pattern
or set of patterns, and/or (iii) an acceptable color or set of
colors. Additionally or alternatively, the fraudulent document
detection rules may specify an acceptable field location.
X. Additional Considerations
[0195] The following additional considerations apply to the
foregoing discussion. Throughout this specification, plural
instances may implement operations or structures described as a
single instance. Although individual operations of one or more
methods are illustrated and described as separate operations, one
or more of the individual operations may be performed concurrently,
and nothing requires that the operations be performed in the order
illustrated. These and other variations, modifications, additions,
and improvements fall within the scope of the subject matter
herein.
* * * * *