U.S. patent application number 14/815934 was filed with the patent office on 2015-11-26 for method for detecting merchant data breaches with a computer network server.
This patent application is currently assigned to BRIGHTERION, INC.. The applicant listed for this patent is Brighterion, Inc.. Invention is credited to Akli Adjaoute.
Application Number | 20150339673 14/815934 |
Document ID | / |
Family ID | 54556358 |
Filed Date | 2015-11-26 |
United States Patent
Application |
20150339673 |
Kind Code |
A1 |
Adjaoute; Akli |
November 26, 2015 |
METHOD FOR DETECTING MERCHANT DATA BREACHES WITH A COMPUTER NETWORK
SERVER
Abstract
A method for minimizing merchant data breach damage depends on
computers and financial networks to carry out its steps. Every
payment card transaction witnessed each day by a network server is
assessed by a "jury" of fraud classification algorithms and
assigned a fraud-risk-verdict. Those payment transactions receiving
a high-risk-fraud verdict are retained and sorted into a table
according to transaction date, cardholder, and merchant. The raw
verdicts are normalized and standardized according to merchant size
groups, e.g., to even the comparisons that will be made. A daily
tally is made for each merchant of the number of
suspected-card-visits, the number of highly-probable-card-visits,
and the number of total-card-visits. A merchant data-breach alert
is issued if a final score and sum of the normalized verdicts
exceeds a threshold.
Inventors: |
Adjaoute; Akli; (Mill
Valley, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Brighterion, Inc. |
San Francisco |
CA |
US |
|
|
Assignee: |
BRIGHTERION, INC.
San Francisco
CA
|
Family ID: |
54556358 |
Appl. No.: |
14/815934 |
Filed: |
July 31, 2015 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
14815848 |
Jul 31, 2015 |
|
|
|
14815934 |
|
|
|
|
14525273 |
Oct 28, 2014 |
|
|
|
14815848 |
|
|
|
|
Current U.S.
Class: |
705/30 |
Current CPC
Class: |
G06F 21/6245 20130101;
G06F 16/283 20190101; G06Q 40/12 20131203; G06F 16/285 20190101;
G06Q 20/4016 20130101 |
International
Class: |
G06Q 20/40 20060101
G06Q020/40; G06F 17/30 20060101 G06F017/30; G06F 21/62 20060101
G06F021/62; G06Q 40/00 20060101 G06Q040/00 |
Claims
1. A method for minimizing financial damage in merchant data
breaches, and that depends on computers and financial networks to
carry out its steps, comprising: inputting payment authorization
request records of real-time transactions received over a network
from point-of-sale terminals; applying classification algorithms
with a computer programmed for this purpose that depends on any
data warehoused in preconditioned data structures or records;
consulting a population of smart agents with a computer programmed
for this purpose that depends on the data warehoused in said data
structures or records; judging the weights and balances of a
plurality of jurors in a jury panel of classification algorithms
with a computer programmed for this purpose, and that depends on
the data warehoused in said data structures or records; deciding
each payment transaction request with a computer programmed for
this purpose that depends on the data warehoused in said data
structures or records; assessing all such records of payment card
transactions witnessed each day through a network server executing
a jury of fraud classification algorithms that then combine to
allocate a fraud-risk-verdict for each payment card transaction;
retaining those payment transactions having been allocated a
high-risk-fraud verdict that exceeds a threshold value with a
computer programmed for this purpose; sorting any retained payment
transactions receiving a high-risk-fraud into a table according to
transaction date, cardholder, and merchant with a computer
programmed for this purpose; normalizing and standardizing said
sorted and retained high-risk-fraud verdicts according to merchant
size groups for evened comparisons using a multiplier with a
computer programmed for this purpose; making a daily tally for each
merchant of the number of suspected-card-visits, the number of
highly-probable-card-visits, and the number of total-card-visits of
normalized and standardized high-risk-fraud verdicts with a
computer programmed for this purpose; and issuing a merchant
data-breach alert with a computer programmed for this purpose if a
final score and sum of normalized and standardized high-risk-fraud
verdicts in a daily tally exceeds a threshold.
2. The method of claim 1, further comprising: assembling a table
for each merchant manifesting in the records of payment card
transactions with a computer programmed for this purpose; and using
a temporary key in place of an original merchant identifier to make
for a more uniform data type with a computer programmed for this
purpose; excluding records of payment card transactions
corresponding to peak season dates with a computer programmed for
this purpose.
3. The method of claim 1, further comprising with a computer
programmed for this purpose: computing the square root of a
suspected number of card visits, mathematically: Verdict - 1 =
Suspect Card Visits ; ##EQU00006## computing the square root of a
suspected number of card visits divided by all card visits,
mathematically: Verdict - 2 = Suspect Card Visits All Card Visits ;
##EQU00007## computing the square root of the number of highly
probable card visits divided by all card visits, mathematically:
Verdict - 3 = Highly Probable Visits All Card Visits ; ##EQU00008##
and that all then support an allocation of said fraud-risk-verdicts
for each payment card transaction.
4. The method of claim 3, further comprising the steps of: grouping
transaction data received merchants into five size categories
according to the number of card visits associated with them, and
approximating (1) Small: 0 to 1000 cards seen; (2) Medium-Small:
1000 to 2,000 cards seen; (3) Medium: 2,000 to 5,000 cards seen;
Medium-Large: 5,000 to 10,000 cards seen; and, Large: 10,000+ cards
seen, all with a computer programmed for this purpose.
5. The method of claim 4, further comprising the steps of:
generating a population of smart agent profiles with a computer
programmed for this purpose by data mining of historical
transaction data, wherein a corresponding number of entities
responsible for each transaction are sorted and each are paired
with a newly minted smart agent profile; modeling with a computer
programmed for this purpose each smart agent profile so generated
to collect and list individual and expanded attributes of said
transactions in one column dimension and by time interval series in
another row dimension; storing each said smart agent profile with a
computer programmed for this purpose; comparing and contrasting
with a computer programmed for this purpose each transaction record
attribute-by-attribute with a time-interval series of attributes
archived in a paired smart agent profile, and each such comparison
and contrast incrementally increases or decreases a computed
fraud-risk-verdict; and outputting said computed fraud-risk-verdict
with a computer programmed for this purpose as a determination of
whether the newly arriving transaction record represents a genuine
transaction, a suspicious transaction, or a fraudulent
transaction.
6. The of claim 5, further comprising: dividing each said time
interval series with a computer programmed for this purpose into a
real-time part and a long-term part; pre-computing with a computer
programmed for this purpose each real-time part and long-term part
a velocity count and statistics of said individual and expanded
attributes; and comparing transaction records with a computer
programmed for this purpose item-by-item to corresponding items in
each said real-time part and long-term part, and thereby determine
if each item represents fraud.
7. The merchant data breach method of claim 6, further comprising
the steps of: inspecting each newly arriving transaction record
with a computer programmed for this purpose to see if the entity it
represents has not yet been paired to a smart agent profile, and if
not then generating and pairing a newly minted smart agent profile
for it.
8. The merchant data breach method of claim 7, further comprising
the steps of: generating three populations of smart agent profiles
with a computer programmed for this purpose by data mining of
historical transaction data, wherein a corresponding number of
cardholder, merchant, and identified device entities involved in
each transaction are sorted and each are paired with a newly minted
smart agent profile; comparing with a computer programmed for this
purpose each attribute, attribute-by-attribute with a time interval
series of attributes archived in the smart agent profiles paired
with a particular cardholder, and with a particular merchant, and
with a particular identified device, and each such comparison and
contrast incrementally increases or decreases a computed overall
fraud-risk-verdict.
Description
BACKGROUND OF THE INVENTION
[0001] 1. Field of the Invention
[0002] The present invention relates to methods of financial fraud
control and management, and more particularly to using computers
and network servers to raise much earlier alerts whenever a
merchant data breach of payment card accounts has manifested.
[0003] 2. Background
[0004] Serious large scale data breaches are happening regularly
and have been making news every month now for many years. The
latter ones seem bigger in scale than the earlier ones, and the
corporate and government systems that have been compromised had
appeared to be secured with the best techniques and equipment.
Worse, when breaches do occur, it is the abuses of the personal
financial data of individuals that were recorded in the databases
that appears first and raises red flags. It takes sometimes months
before the common denominators (the merchant or agency) are
recognized, and by then serious damage has already developed.
[0005] Cardholders will each individually settle into routine
behaviors, and therefore their payment card transactions will
follow those routines. All cardholders, as a group, are roughly the
same and produce roughly the same sorts of transactions. But on
closer inspection the general population of cardholders will
cluster into various subgroups and behave in similar ways as
manifested in the transactions they generate.
[0006] Card issuers want to encourage cardholders to use their
cards, and want to stop and completely eliminate fraudsters from
being able to pose as legitimate cardholders and get away with
running transactions through to payment. So card issuers are
challenged with being able to discern who is legitimate,
authorized, and presenting a genuine transaction, from the clever
and aggressive assaults of fraudsters who learn and adapt all too
quickly. All the card issuers have before them are the millions of
innocuous transactions flowing in every day.
[0007] Consumers who shopped at Target Stores the three weeks
between Nov. 27, 2013 and Dec. 18, 2013, received notice that their
personal information was compromised, and were therefore eligible
for money from a nationwide Data Breach Settlement. Target agreed
to set aside $19 million for the 40 million credit and debit card
accounts that various MasterCard banks and credit unions that had
issued and had been swept up in the breach. Target disclosed the
massive breach on Dec. 19, 2013, during the peak of that year's
holiday shopping season. The Disclosure distressed all shoppers who
then avoided the retailer in masses, fearing the lack of Target
security would expose their private data. That significantly
depressed Target's profits and sales for months thereafter. And as
of July 2015, the major issues falling out of this Breach remain
unresolved.
[0008] What is needed is a method of fraud management that can
tightly follow and monitor the behavior of all payment-card holders
and merchants. And then act quickly in real-time when a fraudster
has, with a single compromise of a large merchant, put the millions
of customers of that merchant at risk for financial losses because
their personal and account information are now subject to immediate
worldwide abuse by criminals.
SUMMARY OF THE INVENTION
[0009] Briefly, a method embodiment of the present invention
depends on computers and financial networks to carry out its steps.
Every payment transaction occurring each day is assessed by a
"jury" of fraud classification algorithms and assigned a
fraud-risk-verdict. Those payment transactions receiving the
high-risk-fraud verdicts are retained and sorted into a table
according to transaction date, cardholder, and merchant. The
verdicts are normalized and standardized according to merchant size
groups, e.g., to even the comparisons that will be made. A daily
tally is made for each merchant of the number of
suspected-card-visits, the number of highly-probable-card-visits,
and the number of total-card-visits. A merchant data-breach alert
is issued if a final score and sum of the normalized verdicts
exceeds a threshold.
[0010] The above and still further objects, features, and
advantages of the present invention will become apparent upon
consideration of the following detailed description of specific
embodiments thereof, especially when taken in conjunction with the
accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
[0011] FIG. 1 is diagram illustrating the steps of the method for
raising much earlier alerts whenever a merchant data breach of
payment card accounts has manifested;
[0012] FIG. 2 is a functional block diagram of the equipment needed
to perform the steps of the method of FIG. 1;
[0013] FIG. 3 is diagram illustrating the steps of the method for
empaneling a jury of fraud classification algorithms that are
included in the method of FIG. 1;
[0014] FIG. 4 is functional block diagram of a real-time payment
fraud management system as an applied payment fraud model;
[0015] FIG. 5 is functional block diagram of a smart agent process
embodiment of the present invention;
[0016] FIG. 6 is functional block diagram of a most recent
fifteen-minute transaction velocity counter;
[0017] FIG. 7 is functional block diagram of a cross-channel
payment fraud management embodiment of the present invention;
[0018] FIG. 8 is a diagram of a group of smart agent profiles
stored in a custom binary file;
[0019] FIG. 9 is a diagram of the file contents of an exemplary
smart agent profile;
[0020] FIG. 10 is a diagram of a virtual addressing scheme used to
access transactions in atomic time intervals by their smart agent
profile vectors;
[0021] FIG. 11 is a diagram of a small part of an exemplary smart
agent profile that spans several time intervals;
[0022] FIG. 12 is a diagram of a behavioral forecasting aspect of
the present invention;
[0023] FIG. 13 is a diagram representing a simplified smart agent
profile and how individual constituent datapoints are compared to
running norms and are accumulated into an overall risk score;
[0024] FIG. 14 is a functional block diagram of a modeling and
operational environment in which an application development system
is used initially to generate, launch, and run millions of smart
agents and their profiles;
[0025] FIGS. 15A-15E represent the statistics and computations
steps included in a data breach detection system embodiment of the
present invention; and
[0026] FIG. 16 is a graph of the verdicts computed from historical
data for Target from November 2013 to January 2014.
DETAILED DESCRIPTION OF THE INVENTION
[0027] This application is a continuation-in-part of U.S. patent
application Ser. No. 14/525,273, filed Oct. 28, 2014, DATA BREACH
DETECTION, and was published as US 2015-0073981 A1. This
application is a continuation-in-part of U.S. patent application
Ser. No. 14/815,848 filed Jul. 30, 2015, AUTOMATION TOOL
DEVELOPMENT METHOD FOR BUILDING COMPUTER FRAUD MANAGEMENT
APPLICATIONS. Such are incorporated by reference herein, in
full.
[0028] In the first Parent Application, a method embodiment of the
present invention is described that depends on computers and
financial networks to carry out its steps. Every payment
transaction occurring each day is assessed by a "jury" of fraud
classification algorithms and given a fraud-risk-verdict. Those
payment transactions receiving high-risk-fraud verdicts are
retained and sorted into a table according to transaction date,
cardholder, and merchant. The verdicts are normalized and
standardized according to merchant size groups to even the
comparisons that will be made. A daily tally is made of the number
of suspected-card-visits, highly-probable-card-visits, and
total-card-visits per merchant. A merchant data-breach alert is
issued if a final score and sum of the normalized verdicts exceeds
a threshold.
[0029] In a method embodiment 100 of FIG. 1, a step 102 empanels a
jury of fraud classification algorithms to receive a stream of
transaction records in a step 104. The jury is charged in a step
106 with rendering millions of ballots of fraud-risk-verdicts
daily. Each fraud-risk-verdict represents a blending of the
opinions of each juror, and the combination verdict is assigned to
a scale. A step 108 sorts the fraud-risk-verdicts according to the
merchant involved. A step 110 normalizes the scaled
fraud-risk-verdicts. A step 112 dismisses those transaction records
having a fraud-risk-verdict scaled below a threshold value. A step
114 tallies the number of suspected-card-visits, the number of
highly-probable-card-visits, and the number of total-card-visits
per merchant. A step 116 issues a merchant data-breach alert if a
final score and sum of the normalized verdicts exceeds a
threshold.
[0030] The "jury" of fraud classification algorithms is just that,
a heterogeneous mix of traditional fraud classification algorithms
is empaneled like a courtroom jury to each hear the evidence in
unison. Some deliberation may occur, and a "judge" may provide
formal controls. The Jury produces fraud-risk-verdicts for each
payment transaction presented that day on a financial network.
Network servers and broadband communications equipment are needed
to keep up with the millions of records involved in the
milliseconds of time that can be afforded.
[0031] General payment fraud algorithms are "trained" with archives
of supervised and unsupervised data to produce a ready-to-use
merchant data breach application. Really what occurs is various
parameters in the framework are initialized. These trained payment
fraud algorithms can then be sold to assist third parties in their
use of our fraud management methods. Commercial clients are
challenged with processing real-time transactions and authorization
requests for fraud verdicts. The applied payment fraud algorithms
are further able to accept ongoing client tuning.
[0032] Our particular brand of smart agents results from the
preoperational data mining of transaction records which can
recognize the many actors and entities behind payment transactions
and their individual characteristic behaviors. For example, the
merchants. These can be effectively understood in their essential
aspects by way of the attributes reported in each transaction they
initiate over time.
[0033] Occasionally each legitimate cardholder will step way
out-of-character and generate a transaction that looks suspicious
or downright fraudulent. Often such transactions can be forecast by
previous such outbursts that they or their peers engaged in. FIG. 3
represents a method 300 of automation tool development for building
general computer fraud management applications for third
parties.
[0034] FIG. 2 illustrates the computer and network machinery
required to implement the Method of FIG. 1. There are three phases
of development, customization/preparation, and application involved
that occur one after the other and in that order. In the
development phase, historical transaction records 202 of a
plurality of financial institutions are "poured" into a database
204 that accumulates and stores these records. A computer and
operator console 206 are programmed to extract fraud classification
parameters for several different classification algorithms 208-213
in parallel from the same collection points provided by database
204.
[0035] These classification algorithms 208-213 and their respective
fraud classification parameters are bound together into a general
purpose "jury" device 214 by a computer program compiler, jury
assembler 216.
[0036] Jury device 214 is a transportable computer program record
that is embodied on a disk, a tape, a file, a data packet, etc. It
is also the tangible thing that can be advertised, marketed, sold,
delivered, and installed on a third party computer data processing
method.
[0037] A second phase, customization and preparation, occurs at a
secure end user location. There, a proprietary transaction record
file 220 is used to build an accumulation of training records in a
database 222. A specialization training processor 224 n a data
processing method fine-tunes the parameters embedded in jury device
214 according to the end users' own experiences and preferences. A
fully operational and ready-to-use jury device 228 is then used in
the third phase.
[0038] A third phase is the application and real-time use. In a
conventional financial payment method that allows shoppers to use
credit cards, debit cards, and other payment cards, millions of
point-of-sale (POS) terminals 230 collect card-present and
card-not-present account information and make payment requests in
secure messages carried in data packets over computer networks. For
example, a secure computer communications financial network 232.
These payment requests are all forwarded by a network server 234 to
a payments processor 236. The individual transaction particulars
are sent by network data packets to a fraud scoring processor 238.
Such is expected to return a payment authorization quickly, within
milliseconds back to POS 230. A credit card issuer and payments
processing business is highly dependent on how well a job is done
by the fraud scoring processor 238.
[0039] The method of FIG. 3 and the computer hardware used to
produce ready-to-use jury device 228 will improve business profits
by reducing losses due to fraud, transactions that should have been
denied, and lost revenues, sales losses due to transactions that
were denied but were in fact legitimate or advantageous.
[0040] The ready-to-use jury device 228 is therefore installed in
the end users' applications and run daily.
[0041] Referring now to FIG. 3, in a method 300, a step 302 uses a
computer development method to assemble together what constitutes a
"jury" of "jurors" that will all be later connected together in
parallel to receive the same payment transaction information data
from a network, transaction-by-transaction. But each such juror
will come to their own conclusions and fraud classifications,
respectively, according to their unique artificial intelligence
(AI) talents, skills, experience, and abilities to learn. Not
unlike how human juries function in courtrooms, but here, millions
of "verdicts" per second are the norm. Computer servers and
networks are therefore necessary to implement these methods.
[0042] Each such AI juror resembles, in computer data processing
terms, a traditional classification technology in algorithm form,
and the spectrum includes decision trees, case-based reasoning,
neural networks, genetic algorithms, etc. These jurors are joined
by a very special juror, the present inventor's own unique "smart
agent" AI algorithms that spawn and assign an individual smart
agent to every actor, entity, or thing discernible from
preoperational data mining of past payment transaction records.
[0043] These smart agents are relied on in the method to track,
follow, and profile the short-term, long-term, and recursive
payment-transaction behaviors of each actor, entity, or thing found
in the data mining. And then to develop a computed statistic, or
abstract, of the mean behavior. New behavior observations can be
matched to these profiles as templates to discern instances of
out-of-character behavior, and probable fraud.
[0044] "False positives" occur when any fraud automation gets it
wrong, e.g., a legitimate transaction is blocked as being
fraudulent. False negatives can also be damaging to a business
because real fraud was able to hide from detection.
[0045] A step 304 uses a data-mining computer especially programmed
to extract, in parallel, initial sets of operating parameters from
millions of instances of transactions previously processed. Each
juror in a jury of fraud classification algorithms reads from the
same historical record of payment transactions.
[0046] A step 306 initializes addresses in a non-volatile
programmable computer memory with several of the initial sets of
operating parameters, together with corresponding computer
implementations of the jury of fraud classification algorithms, to
produce a commercially deliverable and trainable general payment
fraud algorithm computer-program executable that is then operable
on a third party computer method.
[0047] A step 308 is installing the general payment fraud algorithm
computer-program executable onto a third party computer method.
[0048] A step 310 is modifying the memory programming of the
initial sets of operating parameters with data obtained from
records of payment transactions processed for payment authorization
requests received by the third party computer method.
[0049] A step 312 is automatically deciding with a classification
algorithm whether to approve individual payment authorization
requests received by the third party computer method based on a
jury-verdict ballot by each of the jury of fraud classification
algorithms operating within and each respectively using modified
sets of the initial operating parameters.
[0050] And a step 314 is communicating a payment authorization
decision over a computer network to a remote point-of-sale.
[0051] Incremental learning technologies are embedded in the
machine algorithms and smart-agent technology to continually
re-train from any false positives and negatives that occur along
the way. Each corrects itself to avoid repeating the same
classification errors. Data mining logic incrementally changes the
decision trees by creating a new link or updating the existing
links and weights. Neural networks update the weight matrix, and
case based reasoning logic updates generic cases or creates new
ones. Smart-agents update their profiles by adjusting the
normal/abnormal thresholds, or by creating exceptions.
[0052] In general, embodiments of the present invention deliver an
automation tool for the application development of multi-discipline
artificial intelligence fraud management systems. An expert
programmer development method with tools and software libraries is
used for building trainable general payment fraud algorithms that
are constructed of and integrate several artificial intelligence
classifiers, including smart agents, neural networks, case-based
reasoning, decision trees, and business rules. The trainable
general payment fraud algorithms are capable of being trained with
historical transaction data that causes an initial population of
smart agents and associated profiles to be generated, and an
initial set of neural networks to assume a beginning weight matrix,
and an initial decision tree to be structured from data mining
logic, and an initial case-based reasoning set to be structured,
and an initial set of business rules to be fixed. These trainable
general payment fraud algorithms are detachable and deliverable to
third parties once built.
[0053] An incremental learning technology is embedded in a runtime
machine algorithm and smart-agent technology that is able to
continually re-train the artificial intelligence classifiers using
feedback, e.g., false positives and negatives that occur during
use.
[0054] Data mining logic is leveraged to incrementally change the
initial decision trees by creating new links or updating their
existing links and weights. Feedback also is helpful for the
initial neural networks to have their weight matrices updated, and
for the initial case-based reasoning logic to update its generic
cases or to create new ones. The initial population of smart-agents
are enabled to self-update their profiles and to adjust their
normal/abnormal thresholds or by creating exceptions.
[0055] The unique and novel technology of the present inventor, Dr.
Akli Adjaoute, and his Company, Brighterion, Incorporated (San
Francisco, Calif.), is to integrate several different traditional
classification algorithms into a "jury" in which each "juror" hears
the same evidence but arrives at their respective verdicts from
their unique perspectives. A majority vote would be one way to
reach a "verdict", but here the respective qualifications of the
individual jurors can be analyzed and weighed into a final verdict
of "payment fraud" or no fraud. The verdict determines whether the
payment request is approved or declined.
[0056] At the most elementary level, each smart agent begins as a
list of transactions for the corresponding actor or entity that
were sorted from the general inflow of transactions. Each list
becomes a profile and various velocity counts are pre-computed to
make later real-time access more efficient and less burdensome. For
example, a running total of the transactions is maintained as an
attribute datapoint, as are the minimums, maximums, and averages of
the dollar amounts of all long term or short term transactions. The
frequency of those transactions per atomic time interval is also
preprocessed and instantly available in any time interval. The
frequencies of zipcodes involved in transactions is another
velocity count. The radius of those zipcodes around the cardholders
home zipcode can be another velocity count from a
pre-computation.
[0057] So, each smart agent is a two-dimensional thing in virtual
memory expressing attributes and velocity counts in its width and
time intervals and constituent transactions in its length. As time
moves to the next interval, the time intervals in every smart agent
are effectively shift registered ad pushed down.
[0058] The smart agent profiles can be data mined for purchasing
patterns, e.g., airline ticket purchases are always associated with
car rentals and hotel charges. Concert ticket venues are associated
with high end restaurants and bar bills. These patterns can form
behavioral clusters useful in forecasting.
[0059] FIG. 4 represents a real-time payment fraud management
method 400. A raw transaction separator 402 filters through the
forty or so data items that are relevant to the computing of a
fraud verdict. A method 404 adds timestamps to these relevant
datapoints and passes them in parallel to a selected applied fraud
algorithm 406. This is equivalent to a selected one of applied
fraud algorithms 316-323 in FIG. 3 and applied payment fraud
algorithm 114 in FIG. 1.
[0060] During a session in which the time-stamped relevant
transaction data flows in, a set of classification algorithms
408-410 operate independently according to their respective
natures. A population of smart agents 412 and profilers 414 also
operate on the time-stamped relevant transaction data inflows. Each
new line of time-stamped relevant transaction data will trigger an
update 416 of the respective profilers 414. Their attributes 418
are provided to the population of smart agents 412.
[0061] The classification algorithms 408-410 and population of
smart agents 412 and profilers 414 all each produce an independent
and separate vote or fraud verdict 420-423 on the same line of
time-stamped relevant transaction data. A weighted summation
processor 424 responds to client tunings 426 to output a final
fraud verdict 428.
[0062] FIG. 5 represents a smart agent method 500 in an embodiment
of the present invention. For example, these would include the
smart agent population build 334 and profiles 336 in FIG. 3 and
smart agents 412 and profiles 414 in FIG. 4. A series of payment
card transactions arriving in real-time in an authorization request
message is represented here by a random instantaneous incoming
real-time transaction record 502.
[0063] Such record 502 begins with an account number 504. It
includes attributes A1-A9 numbered 505-513 here. These attributes,
in the context of a payment card fraud application would include
datapoints for card type, transaction type, merchant name, merchant
category code (MCC), transaction amount, time of transaction, time
of processing, etc.
[0064] Account number 504 in record 502 will issue a trigger 516 to
a corresponding smart agent 520 to present itself for action. Smart
agent 520 is simply a constitution of its attributes, again A1-A9
and numbered 521-529 in FIG. 5. These attributes A1-A9 521-529 are
merely pointers to attribute smart agents. Two of these, one for A1
and one for A2, are represented in FIG. 5. Here, an A1 smart agent
530 and an A2 smart agent 540. These are respectively called into
action by triggers 532 and 542.
[0065] A1 smart agent 530 and A2 smart agent 540 will respectively
fetch correspondent attributes 505 and 506 from incoming real-time
transaction record 502. Smart agents for A3-A9 make similar fetches
to themselves in parallel. They are not shown here to reduce the
clutter for FIG. 5 that would otherwise result.
[0066] Each attribute smart agent like 530 and 540 will include or
access a corresponding profile datapoint 536 and 546. This is
actually a simplification of the three kinds of profiles 336 (FIG.
3) that were originally built during training and updated in update
416 (FIG. 4). These profiles are used to track what is "normal"
behavior for the particular account number for the particular
single attribute.
[0067] For example, if one of the attributes reports the MCC's of
the merchants and another reports the transaction amounts, then if
the long-term, recursive, and real time profiles for a particular
account number x shows a pattern of purchases at the local Home
Depot and Costco that average $100-$300, then an instantaneous
incoming real-time transaction record 502 that reports another $200
purchase at the local Costco will raise no alarms. But a sudden,
unique, inexplicable purchase for $1250 at a New York Jeweler will
and should throw more than one exception.
[0068] Each attribute smart agent like 530 and 540 will further
include a comparator 537 and 547 that will be able to compare the
corresponding attribute in the instantaneous incoming real-time
transaction record 502 for account number x with the same
attributes held by the profiles for the same account. Comparators
537 and 547 should accept some slack, but not too much. Each can
throw an exception 538 and 548, as can the comparators in all the
other attribute smart agents. It may be useful for the exceptions
to be a fuzzy value, e.g., an analog signal 0.0 to 1.0. Or it could
be a simple binary one or zero. What sort of excursions should
trigger an exception is preferably adjustable, for example with
client tunings 426 in FIG. 4.
[0069] These exceptions are collected by a smart agent risk
algorithm 550. One deviation or exception thrown on any one
attribute being "abnormal" can be tolerated if not too egregious.
But two or more should be weighted more than just the simple sum,
e.g., (1+1).sup.n=2.sup.n instead of simply 1+1=2. The product is
output as a smart agent risk assessment 552. This output is the
equivalent of independent and separate vote or fraud verdict 423 in
FIG. 4.
[0070] FIG. 6 represents a most recent 15-minute transaction
velocity counter 600, in an embodiment of the present invention. It
receives the same kind of real-time transaction data inputs as were
described in connection with FIG. 4 as raw transaction data 402 and
FIG. 5 as records 502. A raw transaction record 602 includes a
hundred or so datapoints. About forty of those datapoints are
relevant to fraud detection an identified in FIG. 6 as reported
transaction data 604.
[0071] The reported transaction data 604 arrive in a time series
and randomly involve a variety of active account numbers. But,
let's say the most current reported transaction data 604 with a
time age of 0:00 concerns a particular account number x. That fills
a register 606.
[0072] Earlier arriving reported transaction data 604 build a
transaction time-series stack 608. FIG. 6 arbitrarily identifies
the respective ages of members of transaction time-series stack 608
with example ages 0:73, 1:16, 3:11, 6:17, 10:52, 11:05, 13:41, and
14:58. Those aged more than 15-minutes are simply identified with
ages ">15:00". This embodiment of the present invention is
concerned with only the last 15-minutes worth of transactions. As
time passes transaction time-series stack 608 pushes down.
[0073] The key concern is whether account number x has been
involved in any other transactions in the last 15-minutes. A search
method 610 accepts a search key from register 606 and reports any
matches in the most 15-minute window with an account activity
velocity counter 612. Too much very recent activity can hint there
is a fraudster at work, or it may be normal behavior. A trigger 614
is issued that can be fed to an additional attribute smart agent
that is included with attributes smart agents 530 and 540 and the
others in parallel. Exception from this new account activity
velocity counter smart agent is input to smart agent risk algorithm
550 in FIG. 5.
[0074] FIG. 7 represents a cross-channel payment fraud management
embodiment of the present invention, and is referred to herein by
general reference numeral 700.
[0075] Real-time cross-channel monitoring uses track cross channel
and cross product patterns to cross pollinate information for more
accurate decisions. Such track not only the channel where the fraud
ends but also the initiating channel to deliver a holistic fraud
monitoring. A standalone internet banking fraud solution will allow
a transaction if it is within its limits, however if core banking
is in picture, then it will stop this transaction, as we
additionally know the source of funding of this account (which
mostly in missing in internet banking).
[0076] In FIG. 3, a variety of selected applied fraud algorithms
316-323 represent the applied fraud algorithms 114 that result with
different settings of filter switch 306. A real-time cross-channel
monitoring payment network server can be constructed by running
several of these selected applied fraud algorithms 316-323 in
parallel.
[0077] FIG. 7 represents a real-time cross-channel monitoring
payment network server 700, in an embodiment of the present
invention. Each customer or accountholder of a financial
institution can have several very different kinds of accounts and
use them in very different transactional channels. For example,
card-present, domestic, credit card, contactless. So in order for a
cross-channel fraud detection method to work at its best, all the
transaction data from all the channels is funneled into one pipe
for analysis.
[0078] Real-time transactions and authorization requests data is
input and stripped of irrelevant datapoints by a method 702. The
resulting relevant data is time-stamped in a method 704. The
15-minute vector method of FIG. 6 may be engaged at this point in
background. A bus 706 feeds the data in parallel line-by-line,
e.g., to a selected applied fraud channel algorithm for card
present 708, domestic 709, credit 710, contactless 711, and high
risk MCC 712. Each can pop an exception to the current line input
data with an evaluation flag or verdict 718-722. The involved
accountholder is understood.
[0079] These exceptions are collected and analyzed by a method 724
that can issue alert feedback for the profiles maintained for each
accountholder. Each selected applied fraud channel algorithm
708-712 shares risk information about particular accountholders
with the other selected applied fraud algorithms 708-712. A
suspicious or outright fraudulent transaction detected by a first
selected applied fraud channel algorithm 708-712 for a particular
customer in one channel is cause for a risk adjustment for that
same customer in all the other applied fraud algorithms for the
other channels.
[0080] Exceptions 718-722 to an instant transactions on bus 706
trigger an automated examination of the customer or accountholder
involved in a profiling method 724, especially with respect to the
15-minute vectors and activity in the other channels for the
instant accountholder. A client tuning input 726 will affect an
ultimate accountholder fraud scoring output 728, e.g., by changing
the respective risk thresholds for
genuine-suspicious-fraudulent.
[0081] A corresponding set of alert triggers 73-734 is fed back to
all the applied fraud channel algorithms 708-712. The compromised
accountholder result 728 can be expected to be a highly accurate
and early protection alert.
[0082] In general, a method for cross-channel financial fraud
protection comprises training a variety of real-time, risk-scoring
fraud algorithms with training data selected for each from a common
transaction history to specialize each member in the monitoring of
a selected channel. Then arranging the variety of real-time,
risk-scoring fraud algorithms after the training into a parallel
arrangement so that all receive a mixed channel flow of real-time
transaction data or authorization requests. The parallel
arrangement of diversity trained real-time, risk-scoring fraud
algorithms is hosted on a network server platform for real-time
risk scoring of the mixed channel flow of real-time transaction
data or authorization requests. Risk thresholds are immediately
updated for particular accountholders in every member of the
parallel arrangement of diversity trained real-time, risk-scoring
fraud algorithms when any one of them detects a suspicious or
outright fraudulent transaction data or authorization request for
the accountholder. So, a compromise, takeover, or suspicious
activity of the accountholder's account in any one channel is
thereafter prevented from being employed to perpetrate a fraud in
any of the other channels.
[0083] Such method for cross-channel financial fraud protection can
further comprise steps for building a population of real-time and a
long-term and a recursive profile for each the accountholder in
each the real-time, risk-scoring fraud algorithms. Then during
real-time use, maintaining and updating the real-time, long-term,
and recursive profiles for each accountholder in each and all of
the real-time, risk-scoring fraud algorithms with newly arriving
data. If during real-time use a compromise, takeover, or suspicious
activity of the accountholder's account in any one channel is
detected, then updating the real-time, long-term, and recursive
profiles for each accountholder in each and all of the other
real-time, risk-scoring fraud algorithms to further include an
elevated risk flag. The elevated risk flags are included in a final
risk verdict calculation 728 for the current transaction or
authorization request.
[0084] The 15-minute vectors described in FIG. 6 are a way to cross
pollenate risks calculated in one channel with the others. The
15-minute vectors can represent an amalgamation of transactions in
all channels, or channel-by channel. Once a 15-minute vector has
aged, it can be shifted into a 30-minute vector, a one-hour vector,
and a whole day vector by a simple shift register means. These
vectors represent velocity counts that can be very effective in
catching fraud as it is occurring in real time.
[0085] In every case, embodiments of the present invention include
adaptive learning that combines three learning techniques to evolve
the artificial intelligence classifiers, e.g., 408-414. First is
the automatic creation of profiles, or smart-agents, from
historical data, e.g., long-term profiling. See FIG. 3. The second
is real-time learning, e.g., enrichment of the smart-agents based
on real-time activities. See FIG. 4. The third is adaptive learning
carried by incremental learning algorithms. See FIG. 7.
[0086] For example, two years of historical credit card
transactions data needed over twenty seven terabytes of database
storage. A smart-agent is created for each individual card in that
data in a first learning step, e.g., long-term profiling. Each
profile is created from the card's activities and transactions that
took place over the two year period. Each profile for each
smart-agent comprises knowledge extracted field-by-field, such as
merchant category code (MCC), time, amount for an mcc over a period
of time, recursive profiling, zip codes, type of merchant, monthly
aggregation, activity during the week, weekend, holidays, Card not
present (CNP) versus card present (CP), domestic versus
cross-border, etc. this profile will highlights all the normal
activities of the smart-agent (specific card).
[0087] Smart-agent technology has been observed to outperform
conventional artificial and machine learning technologies. For
example, data mining technology creates a decision tree from
historical data. When historical data is applied to data mining
algorithms, the result is a decision tree. Decision tree logic can
be used to detect fraud in credit card transactions. But, there are
limits to data mining technology. The first is data mining can only
learn from historical data and it generates decision tree logic
that applies to all the cardholders as a group. The same logic is
applied to all cardholders even though each merchant may have a
unique activity pattern and each cardholder may have a unique
spending pattern.
[0088] A second limitation is decision trees become immediately
outdated. Fraud schemes continue to evolve, but the decision tree
was fixed with examples that do not contain new fraud schemes. So
stagnant non-adapting decision trees will fail to detect new types
of fraud, and do not have the ability to respond to the highly
volatile nature of fraud.
[0089] Another technology widely used is "business rules" which
requires actual business experts to write the rules, e.g.,
if-then-else logic. The most important limitations here are that
the business rules require writing rules that are supposed to work
for whole categories of customers. This requires the population to
be sliced into many categories (students, seniors, zip codes, etc.)
and asks the experts to provide rules that apply to all the
cardholders of a category.
[0090] How could the US population be sliced? Even worse, why would
all the cardholders in a category all have the same behavior? It is
plain that business rules logic has built-in limits, and poor
detection rates with high false positives. What should also be
obvious is the rules are outdated as soon as they are written
because conventionally they don't adapt at all to new fraud schemes
or data shifts.
[0091] Neural network technology also limits, it uses historical
data to create a matrix weights for future data classification. The
Neural network will use as input (first layer) the historical
transactions and the classification for fraud or not as an output).
Neural Networks only learn from past transactions and cannot detect
any new fraud schemes (that arise daily) if the neural network was
not re-trained with this type of fraud. Same as data mining and
business rules the classification logic learned from the historical
data will be applied to all the cardholders even though each
merchant has a unique activity pattern and each cardholder has a
unique spending pattern.
[0092] Another limit is the classification logic learned from
historical data is outdated the same day of its use because the
fraud schemes changes but since the neural network did not learn
with examples that contain this new type of fraud schemes, it will
fail to detect this new type of fraud it lacks the ability to adapt
to new fraud schemes and do not have the ability to respond to the
highly volatile nature of fraud.
[0093] Contrary to previous technologies, smart-agent technology
learns the specific behaviors of each cardholder and create a
smart-agent that follow the behavior of each cardholder. Because it
learns from each activity of a cardholder, the smart-agent updates
the profiles and makes effective changes at runtime. It is the only
technology with an ability to identify and stop, in real-time,
previously unknown fraud schemes. It has the highest detection rate
and lowest false positives because it separately follows and learns
the behaviors of each cardholder.
[0094] Smart-agents have a further advantage in data size
reduction. Once, say twenty-seven terabytes of historical data is
transformed into smart-agents, only 200-gigabytes is needed to
represent twenty-seven million distinct smart-agents corresponding
to all the distinct cardholders.
[0095] Incremental learning technologies are embedded in the
machine algorithms and smart-agent technology to continually
re-train from any false positives and negatives that occur along
the way. Each corrects itself to avoid repeating the same
classification errors. Data mining logic incrementally changes the
decision trees by creating a new link or updating the existing
links and weights. Neural networks update the weight matrix, and
case based reasoning logic updates generic cases or creates new
ones. Smart-agents update their profiles by adjusting the
normal/abnormal thresholds, or by creating exceptions.
[0096] In real-time behavioral profiling by the smart-agents, both
the real-time and long-term engines require high speed transfers
and lots of processor attention. Conventional database systems
cannot provide the transfer speeds necessary, and the processing
burdens cannot be tolerated.
[0097] Embodiments of the present invention include a fast, low
overhead, custom file format and storage engine designed to
retrieve profiles in real-time with a constant low load and save
time. For example, the profiles 336 built in FIG. 3, and long-term,
recursive, and real-time profiles 414 in FIG. 4.
[0098] Referring now to FIG. 8, a group of smart agent profiles is
stored in a custom binary file 800 which starts with a meta-data
section 802 containing a profile definition, and a number of fixed
size profile blocks, e.g., 804, 805, . . . 806 each containing the
respective profiles. Such profiles are individually reserved to and
used by a corresponding smart agent, e.g., profile 536 and smart
agent 530 in FIG. 5. Fast file access to the profiles is needed on
the arrival of every transaction 502. In FIG. 5, account number 504
signals the particular smart agents and profiles to access and that
are required to provide a smart agent risk assessment 552 in
real-time. For example, an approval or a denial in response to an
authorization request message.
[0099] FIG. 9 represents what's inside each such profile, e.g., a
profile 900 includes a meta-data 902 and a rolling list of vectors
904. The meta-data 902 comprises the oldest one's time field 906,
and a record length field 908. Transaction events are timestamped,
recorded, and indexed by a specified atomic interval, e.g., ten
minute intervals are typical, which is six hundred seconds. Each
vector points to a run of profile datapoints that all share the
same time interval, e.g., intervals 910-912. Some intervals will
have no events, and therefore no vectors 904. Here, all the time
intervals less than ninety days old are considered by the real-time
(RT) profiles. Ones older than that are amalgamated into the
respective long-term (LT) profiles.
[0100] What was purchased and how long ago a transaction for a
particular accountholder occurred, and when their other recent
transactions occurred can provide valuable insights into whether
the transactions the accountholder is presently engaging in are
normal and in character, or deviating. Forcing a fraud management
and protection method to hunt a conventional database for every
transaction a particular random accountholder engaged in is not
practical. The account holders' transactions must be pre-organized
into their respective profiles so they are always randomly
available for instant calculations. How that is made possible in
embodiments of the present invention is illustrated here in FIGS.
5, 6, and 8-10.
[0101] FIG. 10 illustrates a virtual memory method 1000 in which a
virtual address representation 1002 is translated into a physical
memory address 1004, and/or a disk block address 1006.
[0102] Profiling herein looks at events that occurred over a
specific span of time. Any vectors that were assigned to events
older than that are retired and made available for re-assignment to
new events as they are added to the beginning of the list.
[0103] The following pseudo-code examples represent how smart
agents (e.g., 412, 550) lookup profiles and make behavior deviation
computations. A first step when a new transaction (e.g., 502)
arrives is to find the one profile it should be directed to in the
memory or filing method.
TABLE-US-00001 find_profile ( T: transaction, PT : Profile's Type )
Begin Extract the value from T for each key used in the routing
logic for PT Combine the values from each key into PK Search for PK
in the in-memory index If found, load the profile in the file of
type PT based on the indexed position. Else, this is a new element
without a profile of type PT yet. End
[0104] If the profile is not a new one, then it can be updated,
otherwise a new one has to be created.
TABLE-US-00002 update_profile ( T: transaction, PT : Profile's Type
) Begin find_profile of type PT P associated to T Deduce the
timestamp t associated to T If P is empty, then add a new record
based on the atomic interval for t Else locate the record to update
based on t If there is no record associated to t yet, Then add a
new record based on the atomic interval for t For each datapoint in
the profile, update the record with the values in T (by increasing
a count, sum, deducing a new minimum, maximum ...). Save the update
to disk End
TABLE-US-00003 compute_profile ( T: transaction, PT : Profile's
Type ) Begin update_profile P of type PT with T Deduce the
timestamp t associated to T For each datapoint DP in the profile,
Initialize the counter C For each record R in the profile P If the
timestamp t associated to R belongs to the span of time for DP Then
update C with the value of DP in the record R (by increasing a
count, sum, deducing a new minimum, maximum ...) End For End For
Return the values for each counter C End
TABLE-US-00004 compute_profile ( T: transaction, PT : Profile's
Type ) Begin update_profile P of type PT with T Deduce the
timestamp t associated to T For each datapoint DP in the profile,
Initialize the counter C For each record R in the profile P If the
timestamp t associated to R belongs to the span of time for DR Then
update C with the value of DB in the record R (by increasing a
count, sum, deducing a new minimum, maximum ...) End For End For
Return the values for each counter C End
[0105] The entity's behavior in the instant transaction is then
analyzed to determine if the real-time (RT) behavior is out of the
norm defined in the corresponding long-term (LT) profile. If a
threshold (T) is exceeded, the transaction risk verdict is
incremented.
TABLE-US-00005 analyze_entity_behavior ( T: transaction ) Begin Get
the real-time profile RT by calling compute_profile( T, real-time )
Get the long-term profile LT by calling compute_profile( T,
long-term ) Analyze the behavior of the entity by comparing its
current behavior RT to its past behavior LT: For each datapoint DP
in the profile, Compare the current value in RT to the one in LT
(by computing the ratio or distance between the values). If the
ratio or distance is greater than the pre-defined threshold, Then
increase the risk associated to the transaction T Else decrease the
risk associated to the transaction T End For Return the global risk
associated to the transaction T End
[0106] The entity's behavior in the instant transaction can further
be analyzed to determine if its real-time (RT) behavior is out of
the norm compared to its peer groups. defined in the corresponding
long-term (LT) profile. If a threshold (T) is exceeded, the
transaction risk verdict is incremented.
[0107] Recursive profiling compares the transaction (T) to the
entity's peers one at a time.
TABLE-US-00006 compare_entity_to_peers ( T: transaction ) Begin Get
the real-time profile RTe by calling compute_profile( T, real-time
) Get the long-term profile LTe by calling compute_profile( T,
long-term ) Analyze the behavior of the entity by comparing it to
its peer groups: For each peer group associated to the entity Get
the real-time profile RTp of the peer: compute_profile( T,
real-time ) Get the long-term profile LTp of the peer:
compute_profile( T, long-term ) For each datapoint DP in the
profile, Compare the current value in RTe and LTe to the ones in
RTp and LTp (by computing the ratio or distance between the
values). If the ratio or distance is greater than the pre-defined
threshold, Then increase the risk associated to the transaction T
Else decrease the risk associated to the transaction T End For End
For Return the global risk associated to the transaction T End
[0108] Each attribute inspection will either increase or decrease
the associated overall transaction risk. For example, a transaction
with a zipcode that is highly represented in the long term profile
would reduce risk. A transaction amount in line with prior
experiences would also be a reason to reduce risk. But an MCC
datapoint that has never been seen before for this entity
represents a high risk. (Unless it could be forecast or otherwise
predicted.)
[0109] One or more datapoints in a transaction can be expanded with
a velocity count of how-many or how-much of the corresponding
attributes have occurred over at least one different span of time
intervals. The velocity counts are included in a calculation of the
transaction risk.
[0110] Transaction risk is calculated datapoint-by-datapoint and
includes velocity count expansions. The datapoint values that
exceed a normative point by a threshold value increment the
transaction risk. Datapoint values that do not exceed the threshold
value cause the transaction risk to be decremented. A positive or
negative bias value can be added that effectively shifts the
threshold values to sensitize or desensitize a particular datapoint
for subsequent transactions related to the same entity. For
example, when an airline expense is certain to be followed by a
rental car or hotel expense in a faraway city. The MCC's for rental
car and hotel expenses are desensitized, as are datapoints for
merchant locations in a corresponding far away city.
[0111] FIG. 11 illustrates an example of a profile 1100 that spans
a number of time intervals t.sub.0 to t.sub.8. Transactions, and
therefore profiles normally have dozens of datapoints that either
come directly from each transaction or that are computed from
transactions for a single entity over a series of time intervals. A
typical datapoint 1110 velocity counts the number of events that
have occurred in the last thirty minutes (count 1112), the last six
hours (count 1114), and the last twenty-four hours (count 1116). In
this example, t.sub.0 had one event, t.sub.1 had 3 events, t.sub.2
had 2 events, t.sub.3 had 3 events, t.sub.4 had 2 events, t.sub.5
had 5 events, t.sub.6 had 3 events, t.sub.7 had one event, and
t.sub.8 had 2 events; therefore, t.sub.2 count 1112=6, t.sub.5
count 1114=16, and t.sub.7 count 1116=20. These three counts,
1112-1116 provide their velocity count computations in a simple and
quick-to-fetch summation.
[0112] FIG. 12 illustrates a behavioral forecasting aspect of the
present invention. A forecast algorithm 1200 engages in a real-time
analysis 1202, consults a learned past behavior 1204, and then
makes a behavioral prediction 1206. For example, the real-time
analysis 1202 includes a flight purchase for $1410.65, an auto pay
for cable for $149.50, and a hotel for $2318.80 in a most recent
event. It makes sense that the booking and payment for a flight
would be concomitant with a hotel expense, both represent travel.
Consulting the learned past behavior 1204 reveals that transactions
for flights and hotels has also been accompanied by a car rental.
So an easy forecast for a car rental in the near future is and easy
and reasonable assumption to make in behavioral prediction
1206.
[0113] Normally, an out-of-character expense for a car rental would
carry a certain base level of risk. But if it can be forecast one
is coming, and it arrives, then the risk can reduced since it has
been forecast and is expected. Embodiments of the present invention
therefore temporarily reduce risk assessments in the future
transactions whenever particular classes and categories of expenses
can be predicted or forecast.
[0114] In another example, a transaction to pay tuition at a local
college could be expected to result in related expenses. So
forecasts for bookstore purchases and ATM cash withdrawals at the
college are reasonable. The bottom-line is fewer false positives
will result.
[0115] FIG. 13 illustrates a forecasting example 1300. A smart
agent profile 1302 has several datapoint fields, field .sub.1
through field .sub.n. Here we assume the first three datapoint
fields are for the MCC, zipcode, and amount reported in a new
transaction. Several transaction time intervals spanning the
calendar year include the months of January . . . December, and the
Thanksgiving and Christmas seasons. In forecasting example 1300 the
occurrence of certain zip codes is nine for 94104, seven for 94105,
and three for 94110. Transaction amounts range $5.80 to $274.50
with an average of $84.67 and a running total of $684.86.
[0116] A first transaction risk example 1304 is timestamped Dec. 5,
2013 and was for an unknown grocery store in a known zipcode and
for the average amount. The risk verdict is thus plus, minus, minus
for an overall low-risk.
[0117] A second transaction risk example 1306 is also timestamped
Dec. 5, 2013 and was for a known grocery store in an unknown
zipcode and for about the average amount. The risk verdict is thus
minus, plus, minus for an overall low-risk.
[0118] A third transaction risk example 1306 is timestamped Dec. 5,
2013, and was for an airline flight in an unknown, far away zipcode
and for almost three times the previous maximum amount. The risk
verdict is thus triple plus for an overall high-risk. But before
the transaction is flagged as suspicious or fraudulent, other
datapoints can be scrutinized.
[0119] Each datapoint field can be given a different weight in the
computation in an overall risk verdict.
[0120] In a forecasting embodiment of the present invention, each
datapoint field can be loaded during an earlier time interval with
a positive or negative bias to either sensitize or desensitize the
category to transactions affecting particular datapoint fields in
later time intervals. The bias can be permanent, temporary, or
decaying to none.
[0121] For example, if a customer calls in and gives a heads up
they are going to be traveling next month in France, then location
datapoint fields that detect locations in France in next months'
time intervals can be desensitized so that alone does not trigger a
higher risk verdict. (And maybe a "declined" response.)
[0122] Some transactions alone herald other similar or related ones
will follow in a time cluster, location cluster, and/or in an MCC
category like travel, do-it-yourself, moving, and even maternity.
Still other transactions that time cluster, location cluster,
and/or share a category are likely to reoccur in the future. So a
historical record can provide insights and comfort.
[0123] FIG. 14 represents the development, modeling, and
operational aspects of a single-platform risk and compliance
embodiment of the present invention that depends on millions of
smart agents and their corresponding behavioral profiles. It
represents an example of how user device identification (Device ID)
and profiling is allied with accountholder profiling and merchant
profiling to provide a three-dimensional examination of the
behaviors in the penumbra of every transaction and authorization
request. The development and modeling aspects are referred to
herein by the general reference numeral 1400. The operational
aspects are referred to herein by the general reference numeral
1402. In other words, compile-time and run-time.
[0124] The intended customers of embodiments of the present
invention are financial institutions who suffer attempts by
fraudsters at payment transaction fraud and need fully automated
real-time protection. Such customers provide the full database
dossiers 1404 that they keep on their authorized merchants, the
user devices employed by their accountholders, and historical
transaction data. Such data is required to be accommodated in any
format, volume, or source by an application development method and
compiler (ADSC) 1406. ADSC 1406 assists expert programmers to use a
dozen artificial intelligence and classification technologies 1408
they incorporate into a variety of fraud algorithms 1410. This
method is more fully described in U.S. patent application Ser. No.
14/514,381, filed Oct. 15, 2014 and titled, ARTIFICIAL INTELLIGENCE
FRAUD MANAGEMENT SOLUTION. Such is fully incorporated herein by
reference.
[0125] One or more trained fraud algorithms 1412 are delivered as a
commercial product or service to a single platform risk and
compliance server with a real-time scoring engine 1414 for
real-time multi-layered risk management. In one perspective,
trained algorithms 1412 can be viewed as efficient and compact
distillations of databases 1404, e.g., a 100:1 reduction. These
distillations are easier to store, deploy, and afford.
[0126] During operation, real-time scoring engine 1414 provides
device ID and clickstream analytics, real-time smart agent
profiling, link analysis and peer comparison for merchant/internal
fraud detection, real-time cross-channel fraud prevention,
real-time data breach detection and identification device ID and
clickstream profiling for network/device protection.
[0127] A real-time smart agent profiling engine 1416 receives
behavioral digests of the latest transactions 1418 and uses them to
update three populations of profiles 1420-1422. Specifically, a
population of card profiles 1420, a population of merchant profiles
1421, and a population of device profiles 1422 all originally
generated by ADSC 1406 and included in the trained algorithms 1412.
These are all randomly and individually consulted in real-time by
smart agent profiling engine 1416 to understand what is "normal"
for a particular card, merchant, and user device.
[0128] Real-time smart agent profiling engine 1416 accepts customer
transaction data and verdicts each line. Such verdicts are in
accordance with business rules provided by a business rules
management method (BRMS) 1424 and any adaptive updates 1426 needed
to the original set of algorithms 1410 produced by artificial
intelligence technologies and classifiers 1408. A web-based case
management method 1428 uses false positives and false negatives to
tighten up algorithms 1410. These are periodically used to remotely
update algorithms 1412.
[0129] In general smart agent method embodiments of the present
invention generate a population of smart agent profiles by data
mining of historical transaction data. A corresponding number of
entities responsible for each transaction are sorted and each are
paired with a newly minted smart agent profile. Each smart agent
profile so generated is modelled to collect and list individual and
expanded attributes of said transactions in one column dimension
and by time interval series in another row dimension. Each smart
agent profile is stored in a file access method of a network server
platform.
[0130] Each newly arriving transaction record is compared and
contrasted attribute-by-attribute with the time interval series of
attributes archived in its paired smart agent profile, and each
such comparison and contrast incrementally increases or decreases a
computed fraud-risk-verdict. The computed fraud-risk-verdict is
thereafter output as a determination of whether the newly arriving
transaction record represents a genuine transaction, a suspicious
transaction, or a fraudulent transaction. Or maybe just OK-bad, or
a fuzzy verdict between 0 . . . 1.
[0131] Each time interval series can be partitioned or divided in
its row dimension into a real-time part and a long-term part to
separately pre-compute from the real-time part and the long-term
part a velocity count and statistics of said individual and
expanded attributes. The newly arriving transaction record is then
compared item-by-item to relevant items in each said real-time part
and long-term part, and thereby determines if each item represents
known behavior or unknown behavior.
[0132] Each newly arriving transaction record is inspected to see
if the entity it represents has not yet been paired to a smart
agent profile, and if not then generating and pairing a newly
minted smart agent profile for it.
[0133] In another embodiment, three populations of smart agent
profiles are generated by learning from the historical transaction
data. A corresponding number of cardholder, merchant, and
identified device entities involved in each transaction are sorted
and each are paired with a newly minted smart agent profile. Then,
each newly arriving transaction record is compared and contrasted
attribute-by-attribute with the time interval series of attributes
archived in the smart agent profiles paired with the particular
cardholder, and with the particular merchant, and with the
particular identified device (Device ID), and each such comparison
and contrast incrementally increases or decreases a computed
overall fraud-risk-verdict. See our U.S. patent application Ser.
No. 14/517,863, filed 19 Oct. 2014, and titled User Device
Profiling In Transaction Authentications, for details on the Device
ID technology we have in mind here.
[0134] DATA BREACH DETECTION: The artificial intelligence and
machine learning techniques described above can be applied a unique
combination to build effective data breach detection systems. A
broad set of data was tested that included daily merchant card
transactions from Nov. 1, 2013 to Dec. 31, 2013. Our analytics were
applied to this dataset, and resulted in a greatly accelerated
detection that a breach had occurred with Target.
[0135] Conventional methods are very slow because the rely on
warehouses of already confirmed fraud.
[0136] FIGS. 15A, 15B, and 15C represent a data breach detection
method embodiment of the present invention, and is referred to
herein by the general reference numeral 1500. The object is to
develop an early alert that a merchant has suffered a data breach
of sensitive cardholder and payment information. Data breach
detection method 1500 focuses on the correlations between
cardholders, merchants, and transaction dates in transactions
receiving high-risk-fraud verdicts, e.g., 428 (FIG. 4), 552 (FIG.
5), 728 (FIG. 7), and 1414 (FIG. 14).
[0137] In tests with historical transaction data involving Target
Corporation Stores, fraud verdicts such as these rose sharply at
the same time the criminals begin their "test and try" activity.
E.g., the first week of December. The following Table is of
selected key variables that were used to drive the analytics.
Moderate increases in fraud are customary and expected during the
days following Thanksgiving (Black Friday weekend). But Target
Corporation saw a steady increase in suspicious card use. They also
saw cards with confirmed fraud which had only been used at Target
during the period in question.
TABLE-US-00007 TABLE Selected Key Variables Suspicious card Cards
with high fraud verdicts, only Transaction use over the used at
Target, Date monitoring period over the monitoring period Nov. 27,
2013 0.214% 0.002% Nov. 28, 2013 0.216% 0.002% Nov. 29, 2013 0.218%
0.002% Nov. 30, 2013 0.231% 0.002% Dec. 1, 2013 0.254% 0.003% Dec.
2, 2013 0.267% 0.003% Dec. 3, 2013 0.276% 0.003% Dec. 4, 2013
0.302% 0.003% Dec. 5, 2013 0.306% 0.003% Dec. 6, 2013 0.307% 0.003%
Dec. 7, 2013 0.309% 0.003% Dec. 8, 2013 0.310% 0.003% Dec. 9, 2013
0.304% 0.003% Dec. 10, 2013 0.300% 0.003% Dec. 11, 2013 0.298%
0.003% Dec. 12, 2013 0.299% 0.003% Dec. 13, 2013 0.301% 0.003% Dec.
14, 2013 0.304% 0.003% Dec. 15, 2013 0.304% 0.003% Dec. 16, 2013
0.302% 0.003% Dec. 17, 2013 0.299% 0.004%
[0138] A comparison was made of the data breach detection method
verdicts between Target and other merchants that cater to a similar
demographic and during the same time period. The verdicts showed
that cards used at Target displayed behaviors that were clearly
irregular, and evidence of abnormal behavior became clear as early
as the first week of December.
[0139] The data breach detection method verdicts for Target were
contrasted with an online gaming merchant's verdicts. The online
gaming merchant had a higher baseline of fraud, but their verdicts
held steady during the timeframe of Target's breach.
[0140] The data breach detection method tests examined network
level data, but would also be effective when applied to a large
issuer or processor's dataset. Data breach detection method
embodiments of the present invention snaps quicker to anomalous
behaviors that are suggestive of a breach. As such, their use can
minimize looming negative impacts.
[0141] Data breach detection method embodiments of the present
invention analyze fraudulent card activities and evaluate real-time
transactions to determine if any come from a compromised merchant,
before waiting for transactions to be reported as fraudulent by the
cardholder. These data breach detection systems use the daily
transactions to collect all cards with a large fraud verdict (very
high risk). A lowered verdict threshold allows a larger more
sensitive detection rate of all frauds, while a higher setting will
reduce false positives.
[0142] In tests, some transactions that were considered to be
fraudulent were often the fallout from aggressive merchants. Such
merchants force subscriptions and reoccurring payments that are
difficult to cancel and often misunderstood by customers. So since
these are not the result of a data breach, a filter was placed on
the initial fraud card collection to exclude reoccurring
transactions.
[0143] Newly acquired fraudulent cards are often tested by
criminals to see if the cards will still work, before stepping up
to more serious levels of fraud. These test transactions are always
for small amounts, and will not be detected and reported as fraud,
even though they are. So in the tests, a filter was placed on
seemingly genuine transactions to exclude transactions of $2.00 or
less. It is anticipated that including only transactions of $2.00
or less could lead to detecting test merchants, as opposed to a
data breach.
[0144] A table is assembled for each merchant in the reported high
risk transaction data. A temporary key is used in place of the
original merchant identifier to make for a more uniform data type.
Transactions for peak season dates, such Black Friday to Cyber
Monday, were dropped. The card information, merchant information,
and how the combinations of card/merchants interact and the last
time each card visits a particular merchant were grouped together.
The merchants each cardholder visited were ranked "1" (first), to
the last, but no higher than "100".
[0145] A larger information matrix organizing the merchant and card
information was created after cleaning up the data. Each row
represented a different card, and a list of the past one hundred
merchants they visited, which allowed a quick broad view of
events.
[0146] In a next step, the card and merchant matrix is evaluated,
by summing over rows and then the columns to create scoring
criteria that spans more than one statistic at a time. These
verdicts are balanced, adjusted, and combined into a singular final
verdict. A summary table for each outlet, and initial scoring
criteria is created. The summary table included the number of
suspect cards that visited, the sum of the percentages of those
cards visits, and more advanced strategies still being testing.
Each outlet has linear combinations of the summary statistics and
initial scoring criteria placed together to come up with a final
verdict. Different strategies are being used, and filters are
edited to help evaluate, understand, and update the verdicts.
[0147] FIG. 15A shows how the daily inflow of transactions 1502 is
fed to a smart agent artificial intelligence fraud scoring platform
1504 to obtain a daily set 1506 of transactions with high fraud
verdicts.
[0148] A number of different statistics are used in the scoring
mechanisms. These fields are highly relevant to data breaches and
helpful for judging the predictions of the final verdicts later.
For example in FIG. 15A these are listed as suspect-card-visits
1510, suspect-card-visits-with decay 1511, highly-probable-visits
1512, highly-probable-visits-with decay 1513, and all-card-visits
1514. Defined another way: [0149] 1. NUMBER_OF_CARDS [0150] a. This
is the total number of different cards (Genuine and Suspect) seen
by a merchant in the past, e.g., 30 days. [0151] b. Used to
differentiate merchant size [0152] c. Inversely proportionate to
the risk of data breach. [0153] 2. SUSPECT_CARD_VISITS [0154] a.
This is the total number of different suspect cards seen by a
merchant in the past, e.g., 30 days. [0155] b. Major part of
scoring for data breach [0156] 3. SUM_PROB_VISITS [0157] a. This is
the total number of suspect cards, which were highly probable to
have been breached at that merchant, seen by a merchant in the
past, e.g., 30 days. [0158] b. These combinations are considered
more high risk because the card has only visited that merchant in
this time period. [0159] 4. SUSPECT_CARD_VISITS_DCY [0160] a.
Similar to SUSPECT_CARD_VISITS, but includes a decaying function
based on how many merchants were visited between the current
merchant and the suspected fraud. [0161] b. Not currently used, but
available for continued future analysis. [0162] 5.
SUM_PROB_VISITS_DCY [0163] a. Similar to SUM_PROB_VISITS, but cards
which have visited more than one merchant also add to the verdict
proportional to the number of other merchants they have visited.
[0164] b. This version also includes decay similar to
SUSPECT_CARD_VISITS_DCY which is included with the proportional
value change. (This extra decay can be removed). [0165] c. Not
currently used, but available for continued future analysis. [0166]
6. PCT_OFSCARDS_STOLEN_LATER [0167] a. This is
SUSPECT_CARD_VISITS/NUMBER_OF_CARDS=the percentage of suspect cards
out of all cards seen by that merchant. [0168] 7.
SUM_PROB_DIV_NUM_CRD [0169] a. This is
SUM_PROB_VISITS/NUMBER_OF_CARDS=the percentage of suspect cards
that visited only that merchant out of all cards seen by that
merchant. [0170] 8. Run_Date [0171] a. The day that the Data breach
detection method was run on, expected to equal today's date, but
can be different when run over past data for historical
observations and testing.
[0172] Verdict balancing is needed to level the playing field, the
verdicts and other information are collected and used to compare
merchants and determine the optimal strategy for merchant and data
breach risk. Because of the large differences between merchant
sizes, the collected verdicts were weighted in merchant
categorization method 1508 based on how many cards, genuine and
suspect, a merchant has seen within the past thirty days. There are
five main groups 1515, medium-small, medium, and medium-large, and
large. Most merchants judged belonged in the middle three groups:
medium-small, medium, and medium-large.
Group Sizes 1515
[0173] 1. Small: 0 to 1000 cards seen [0174] 2. Medium-Small: 1000
to 2,000 cards seen [0175] 3. Medium: 2,000 to 5,000 cards seen
[0176] 4. Medium-Large: 5,000 to 10,000 cards seen [0177] 5. Large:
10,000 or more cards seen
[0178] Verdict transformations are based on the distributions and
values of the main scoring statistics seen, new derived values are
created. Because many of these verdicts had large disproportionate
distributions, the square root function was used to normalize
significant values and lower outlier values while preserving
verdict rankings.
TABLE-US-00008 VERDICT_1 {square root over (Suspect Card Visits)}
VERDICT_2 Suspect Card Visits All Card Visits ##EQU00001##
VERDICT_3 Highly Probable Visits All Card Visits ##EQU00002##
VERDICT_4 {square root over (Suspect Card Visits (With Decay))}
VERDICT_5 Suspect Card Visits ( With Decay ) All Card Visits
##EQU00003## VERDICT_6 Highly Probable Visits ( With Decay ) All
Card Visits ##EQU00004## VERDICT_7 {square root over (Holidays
Exceptions)} VERDICT_8 Time series / risks orientation Time -
Window ##EQU00005##
[0179] A handful of merchants at the top list were verified in
testing by searching through news reports, articles, and other
media sources available. In FIG. 15B, a verdict-1 1521, a verdict-2
1522, and a verdict-3 1523 were chosen based on their comparative
values for a few known data breaches. These verdicts for known data
breaches were compared to the general population of all verdicts
seen in the set being tested.
[0180] Verdicts 1521-1523 were balanced with others all within each
merchant size group 1515. The center values (median/average) of
Verdict-1 1521 were compared to the center values of Verdict-2 1522
and verdict-3 1523. As seen in FIG. 15B, multipliers for Verdict-2
and Verdict-3 were created based on these numbers. So any merchant
showing a large value, when compared to other merchants in their
group, in one or multiple parts of these verdicts could spring an
alert.
TABLE-US-00009 SIZE ADJUSTMENTS Merchant Verdict-1 Verdict-2
Verdict-3 Flat Size Multiplier Multiplier Multiplier Adjustment
Small 2.76 16 125 0 Medium - 2.52 25 200 0 Small Medium 2.18 40 200
0 Medium - 1.59 70 260 0 Large Large 1 130 500 -75
[0181] A similar multiplier was created for Verdict-1, comparing
the ratio of large Verdict-1 to the other merchant sizes'
Verdict-1. This multiplier adjusts all five groups final verdicts
for the same scale. This allows all merchants, regardless of size,
to be considered for a data breach. This was not done on Verdict-2
and Verdict-3 because they already included the total cards seen
within their calculations.
[0182] Merchants within the Large group have an almost guaranteed
number of suspect transactions due to size alone, Verdict-1 was
seen to have larger minimum and maximums for this group. A flat
value of 75 is deducted from the Large merchant verdicts, these are
determined by where the difference in distributions of initial
combination verdicts for the Large group versus all other
groups.
[0183] In FIG. 15D, after adjustments are made, all verdicts
1521-1528 (FIGS. 15B and 15C) are added together in a summation
method 1530 for each merchant, and final combination verdicts 1540
are created. These verdicts reflect the estimated risks that any
particular merchant suffered a data breach.
[0184] The prototype data breach detection method was rerun using
historical data for each day between Nov. 1, 2013 to Jan. 31, 2014.
The following table includes the top highest scoring merchants
within each merchant group size they belonged to, with the first
date they broke the threshold of 50.0, and with the highest verdict
they ultimately received in the time line.
TABLE-US-00010 MERCHANT FIRST ALERT OUTLET_ID GROUPING DATE TOP
VERDICT 0032861 large 1-Nov-yr 215.019167 0032862 large 1-Nov-yr
158.807118 0032863 large 1-Nov-yr 145.472479 0055411 medium
2-Nov-yr 143.720407 0047981 large 1-Nov-yr 125.645545 0032864 large
1-Nov-yr 122.459354 0082732 large 1-Nov-yr 108.013765 0072601
medium-large 1-Nov-yr 107.884795 0032866 large 1-Nov-yr 105.166112
0039622 medium 1-Nov-yr 104.738724 0082734 medium 1-Nov-yr
103.088835 0029508 small 24-Jan-next year 97.705843 0074780 medium
26-Dec-yr 93.0173564 0067200 medium 29-Dec-yr 90.6907448 0029500
medium 1-Nov-yr 89.9405071
[0185] False positives were still seen as possible, even though
steps were taken to remove aggressive merchants and small-amount
tested merchants from the data. There were some residual effects of
these merchants in the final outcomes. Their effects are considered
to be minimal, and over time any reoccurring alerts on these
merchants would become more evident.
TABLE-US-00011 Run Date NUMBER_OF_CARDS SUSPECT_CARD_VISITS
SUM_PROB_VISITS 18-Nov-yr 5,256,362 11,102 137 19-Nov-yr 5,237,723
10,983 136 20-Nov-yr 5,213,239 10,953 137 21-Nov-yr 5,224,253
11,065 130 22-Nov-yr 5,232,915 11,165 125 23-Nov-yr 5,237,325
11,284 131 24-Nov-yr 5,257,310 11,440 139 25-Nov-yr 5,317,823
11,531 155 26-Nov-yr 5,309,759 11,386 144 27-Nov-yr 5,309,074
11,356 121 28-Nov-yr 5,340,793 11,532 130 29-Nov-yr 5,389,232
11,726 129 30-Nov-yr 5,248,363 12,127 120 1-Dec-yr 5,133,081 13,039
130 2-Dec-yr 5,002,787 13,355 131 3-Dec-yr 4,827,851 13,332 134
4-Dec-yr 4,668,190 14,101 125 5-Dec-yr 4,713,529 14,432 130
6-Dec-yr 4,750,209 14,571 144 7-Dec-yr 4,789,920 14,797 156
[0186] FIG. 15E represents four time series of payment card
transactions 1550 belonging to seemingly unrelated Cardholder-A
1551, Cardholder-B 1552, Cardholder-C 1553, and Cardholder-D 1554.
Cardholder-A and the others all came to the attention of Data
Breach Detection method 1500 by virtue of having had been
associated with a transaction judged as high risk by artificial
intelligence fraud scoring platform 1504. That further instituted a
fetch of all the recent transactions the Cardholder was involved in
with an eye to the merchants or other points-of-compromise (POC)
they visited. Once all the possibly compromised Cardholders have
thus been brought forward, summation method 1530 searches for a POC
intersection 1560. The common intersections are inspected for even
earlier contacts with the POC's. Here, in this example, merchant-R
appears to be a likely point-of-compromise.
[0187] Once a point-of-compromise is in the view-sights of Data
Breach Detection method 1500, all the cardholders and transactions
they handled during a critical time frame can be investigated to
develop a further focus and confirmation. Investigators can thereby
"zoom in" and search for the telltale signs of a data breach.
[0188] FIG. 16 graphs the verdicts computed for a Retailer from the
historical data between November to the next January. About the
same time period, when the fraud verdict for the Retailer broke a
threshold of 50.0, an investigation was made to see what other
merchants also broke the same threshold. Those that did are listed
below, except for merchants which had a verdict of 50.0 or greater
in the previous week. They were excluded.
[0189] Some method embodiments of the present invention include
grouping together card information, merchant information, and any
combinations of card/merchants interact and the last time each card
visits a particular merchant were grouped together with a computer
programmed for this purpose that. The merchants each cardholder
visited were ranked "1" (first), to the last, e.g., no higher than
"100".
[0190] In a next step, the card and merchant matrix is evaluated,
by summing over rows and then the columns to create scoring
criteria that spans more than one statistic at a time. These
verdicts are balanced, adjusted, and combined into a singular final
verdict. A summary table for each outlet, and initial scoring
criteria is created. The summary table included the number of
suspect cards that visited, the sum of the percentages of those
cards visits, and more advanced strategies still being testing.
[0191] NUMBER_OF_CARDS is the total number of different cards
(Genuine and Suspect) seen by a merchant in the past, e.g., 30
days. Used to differentiate merchant size, Inversely proportionate
to the risk of data breach. [0192] SUSPECT_CARD_VISITS is the total
number of different suspect cards seen by a merchant in the past,
e.g., 30 days. Major part of scoring for data breach [0193]
SUM_PROB_VISITS is the total number of suspect cards, which were
highly probable to have been breached at that merchant, seen by a
merchant in the past, e.g., 30 days. These combinations are
considered more high risk because the card has only visited that
merchant in this time period. [0194] SUSPECT_CARD_VISITS_DCY is
similar to SUSPECT_CARD_VISITS, but includes a decaying function
based on how many merchants were visited between the current
merchant and the suspected fraud. [0195] SUM_PROB_VISITS_DCY is
similar to SUM_PROB_VISITS, but cards which have visited more than
one merchant also add to the verdict proportional to the number of
other merchants they have visited. This version also includes decay
similar to SUSPECT_CARD_VISITS_DCY which is included with the
proportional value change. (This extra decay can be removed).
[0196] PCT_OFSCARDS_STOLEN_LATER is
SUSPECT_CARD_VISITS/NUMBER_OF_CARDS=the percentage of suspect cards
out of all cards seen by that merchant. [0197] SUM_PROS_DIV_NUM_CRD
is SUM_PROS_VISITS/NUMBER_OF_CARDS=the percentage of suspect cards
that visited only that merchant out of all cards seen by that
merchant. [0198] Run_Date is the day that the Data breach detection
method was run on, expected to equal today's date, but can be
different when run over past data for historical observations and
testing.
[0199] Verdict balancing levels the playing field. The verdicts and
other information collected are used to compare merchants and
determine the best strategy for merchant and data breach risk. The
large differences in merchant size requires the collected verdicts
to be weighted.
[0200] A merchant categorization method that can be used is based
on how many cards, genuine and suspect, a merchant has seen within
the past thirty days. There are five main groups, medium-small,
medium, and medium-large, and large. Most merchants judged belonged
in the middle three groups: medium-small, medium, and
medium-large.
[0201] Once a point-of-compromise is assessed as likely, all the
cardholders and transactions they handled during a critical time
frame are investigated more fully for confirmation. Investigators
can thereby "zoom in" and search for the telltale signs of a data
breach.
[0202] A merchant data breach method comprises processing daily
payment transaction data with a risk and compliance platform to
obtain a fraud verdict for each constituent transaction. Then
screening through said constituent transactions with
high-risk-fraud verdicts and sorting them into a table according to
transaction date, cardholder, and merchant, and tallying the number
of suspected card visits, highly probable card visits, and total
card visits per merchant. Then scoring the table data according to
suspected card visits, highly probable visits, and all card visits.
And standardizing the verdicts according to merchant size grouping
through the use of multipliers. This is followed by summing the
standardized verdicts together into a final verdict day-by-day. A
final step issues a merchant data breach alert if a final verdict
and sum of the normalized verdicts exceeds a threshold. A timely
alert of an underlying and expanding security rupture caused by a
merchant data breach is issued for damage control and law
enforcement.
[0203] Although particular embodiments of the present invention
have been described and illustrated, such is not intended to limit
the invention. Modifications and changes will no doubt become
apparent to those skilled in the art, and it is intended that the
invention only be limited by the scope of the appended claims.
* * * * *