U.S. patent application number 12/773767 was filed with the patent office on 2010-11-04 for transaction authorization using time-dependent transaction patterns.
Invention is credited to Patrick Faith, Kevin P. Siegel.
Application Number | 20100280950 12/773767 |
Document ID | / |
Family ID | 43031090 |
Filed Date | 2010-11-04 |
United States Patent
Application |
20100280950 |
Kind Code |
A1 |
Faith; Patrick ; et
al. |
November 4, 2010 |
TRANSACTION AUTHORIZATION USING TIME-DEPENDENT TRANSACTION
PATTERNS
Abstract
Systems, apparatus, and methods for authorizing a transaction
initiated by a consumer are provided. A likelihood function can
approximate a pattern of previous transactions and provide a
measure of how likely it is for a transaction to occur as a
function of time. The time of a current transaction can be used to
determine a corresponding likelihood value of a likelihood function
associated with the transaction. The likelihood value can then be
used to determine a score for authorizing the transaction. As the
likelihood corresponds to a particular time of a pattern, the score
can be tailored to the current transaction and achieve greater
accuracy.
Inventors: |
Faith; Patrick; (Pleasanton,
CA) ; Siegel; Kevin P.; (Milpitas, CA) |
Correspondence
Address: |
TOWNSEND AND TOWNSEND CREW LLP
TWO EMBARCADERO CENTER, 8TH FLOOR
SAN FRANCISCO
CA
94111
US
|
Family ID: |
43031090 |
Appl. No.: |
12/773767 |
Filed: |
May 4, 2010 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61175381 |
May 4, 2009 |
|
|
|
Current U.S.
Class: |
705/44 |
Current CPC
Class: |
G06Q 20/4016 20130101;
G06Q 30/02 20130101; G06Q 30/0202 20130101; G06Q 10/06375 20130101;
G06Q 30/0204 20130101; G06Q 30/0269 20130101; G06Q 10/04 20130101;
G06Q 20/40 20130101; G06Q 30/0224 20130101; G06Q 30/0205 20130101;
G06Q 40/00 20130101; G06Q 40/12 20131203 |
Class at
Publication: |
705/44 |
International
Class: |
G06Q 40/00 20060101
G06Q040/00 |
Claims
1. A method of determining authorization of a transaction involving
a consumer, the method comprising: receiving data associated with
the transaction, wherein the data includes a time T of the
transaction; identifying a first likelihood function associated
with the consumer and with the transaction, wherein the first
likelihood function approximates one or more patterns of previously
performed transactions, the first likelihood function having a
respective likelihood value for each of a plurality of times; a
computer system determining a first likelihood value of the first
likelihood function, the first likelihood value providing a measure
of a likelihood of the transaction occurring at the time T; and
determining a score using the first likelihood value, the score
adapted to be used to determine authorization of the
transaction.
2. The method of claim 1, further comprising: receiving data
corresponding to previous transactions; associating one or more
keys with each previous transaction; correlating pairs of previous
transactions, each correlated pair associated with a particular
pair of keys; and for each correlated pair, determining time
intervals between the transactions of the correlated pair; and for
each key pair: tracking numbers of occurrences of correlated pairs
having time intervals within specified time ranges, the
transactions of the correlated pairs being associated with
corresponding keys of the key pair, wherein a likelihood function
for a pattern of a key pair includes the numbers of occurrences of
correlated pairs for a key pair.
3. The method of claim 2, wherein the previous transactions are
associated with the consumer and/or with one or more other
consumers similar to the consumer.
4. The method of claim 1, wherein identifying the first likelihood
function associated with the transaction includes: associating one
or more keys with the transaction, wherein a likelihood function is
associated with an initial key and a final key; and identifying the
first likelihood function as being associated with a first final
key that matches one of the keys associated with the
transaction.
5. The method of claim 4, further comprising: matching the first
final key with one of the keys associated with the transaction
includes broadening the one of the keys associated with the
transaction until the one of the keys associated with the
transaction is equal to a final key of one of a plurality of
likelihood functions.
6. The method of claim 4, further comprising: identifying other
likelihood functions associated with the consumer and with the
transaction; and the computer system determining another likelihood
value for each of the likelihood functions, wherein determining the
score uses the another likelihood values.
7. The method of claim 1, wherein the first likelihood function
approximates one or more patterns of fraudulent transactions, and
wherein the score includes a measure of a likelihood that the
transaction is fraudulent.
8. The method of claim 1, wherein the first likelihood function
approximates one or more patterns of transactions previously
performed by the consumer, and wherein the score includes a measure
of a likelihood that the transaction is consistent with the one or
more patterns.
9. The method of claim 1, wherein the first likelihood function
approximates one or more patterns of transactions previously
performed by consumers to which the consumer is considered similar,
and wherein the score includes a measure of a likelihood that the
transaction is consistent with the one or more patterns.
10. The method of claim 1, further comprising: transmitting the
score to another entity involved in the transaction.
11. The method of claim 10, wherein the another entity is an issuer
of a credit account being used for the transaction.
12. The method of claim 1, wherein the data associated with the
transaction is received from a merchant involved in the
transaction.
13. The method of claim 12, wherein the data associated with the
transaction is received from the merchant in a request for
authorization of the transaction, the method further comprising:
providing an approval to the authorization request when the
transaction is authorized based on the score.
14. The method of claim 1, wherein determining the score using the
likelihood value includes inputting the first likelihood value into
a neural network that has been trained with valid and fraudulent
transactions.
15. The method of claim 1, wherein the transaction data includes a
first amount of the transaction, wherein the first likelihood
function is associated with a range of amounts that includes the
first amount, and wherein other likelihood functions are associated
with different ranges of amounts.
16. The method of claim 1, wherein the computer system is part of a
payment processing network.
17. A computer program product comprising a tangible computer
readable medium storing a plurality of instructions for controlling
one or more processors to perform the method of claim 1.
18. A computer system comprising: one or more processors; and the
computer program product of claim 17.
19. A method of determining authorization of a transaction
involving a consumer, the method comprising: receiving data
associated with the transaction, wherein the data includes a time T
of the transaction; identifying one or more tables associated with
the consumer and with the transaction, each table including a
plurality of values organized along at least one axis, wherein a
first axis of each table corresponds to a plurality of different
time ranges, and wherein the values in each table correspond to a
number of previous transactions occurring within one of the
different time ranges; a computer system determining at least one
value from each table, wherein the at least one value is for a time
range in which the time T corresponds; and determining a score
using the at least one value, the score adapted to be used to
determine authorization of the transaction.
20. The method to claim 19, wherein each table includes a second
axis corresponding to different ranges of amounts for previous
transactions.
21. The method of claim 19, wherein identifying the one or more
tables associated with the transaction includes: associating one or
more keys with the transaction, wherein a table is associated with
an initial key and a final key; and identifying the at least one
table as being associated with a first final key that matches one
of the keys associated with the transaction.
Description
CROSS-REFERENCES TO RELATED APPLICATIONS
[0001] The present application claims priority from and is a
nonprovisional application of U.S. Provisional Application No.
61/175,381, entitled "SYSTEMS AND METHODS FOR DETERMINING
AUTHORIZATION, RISK SCORES, AND PREDICTION OF TRANSACTIONS" filed
May 4, 2009, the entire contents of which are herein incorporated
by reference for all purposes.
[0002] This application is related to commonly owned and
concurrently filed U.S. Patent applications entitled
"PRE-AUTHORIZATION OF A TRANSACTION USING PREDICTIVE MODELING" by
Faith et al. (attorney docket number 016222-046210US), "DETERMINING
TARGETED INCENTIVES BASED ON CONSUMER TRANSACTION HISTORY" by Faith
et al. (attorney docket number 016222-046220US), "DEMOGRAPHIC
ANALYSIS USING TIME-BASED CONSUMER TRANSACTION HISTORIES" by Faith
et al. (attorney docket number 016222-046230US), and
"FREQUENCY-BASED TRANSACTION PREDICTION AND PROCESSING" by Faith et
al. (attorney docket number 016222-046250US), the entire contents
of which are herein incorporated by reference for all purposes.
BACKGROUND
[0003] The present application is generally related to processing
consumer transactions, and more specifically to the authorization
of consumer transactions.
[0004] Many transactions (such as purchases, wire transfers, and
the like) are performed with reference to a payment account, e.g.,
a credit card account, bank account, or other type of account.
These types of accounts are subject to fraud since the money to pay
for the transaction is not directly provided, but is instead
retrieved from the payment account. For example, fraud might occur
when someone other than the credit card holder uses the credit card
number to make a purchase.
[0005] A reduction in fraud may be achieved in different ways. For
example, when a consumer initiates a transaction with a merchant
using a payment account, the merchant can send an authorization
request for the payment account to a payment processing network.
This authorization request can be part of a check for fraud, as
well as a way to ensure that sufficient funds are available to pay
for the transaction. However, the methods for checking for fraud
are often inaccurate or inefficient. For example, a transaction
might be denied even thought the person/entity requesting the
transaction is indeed the true account holder. Also, the time spent
checking for fraud might be long, which discourages the use of the
account.
[0006] Accordingly, it is desirable to provide more accurate and
efficient processing of transactions.
BRIEF SUMMARY
[0007] Embodiments of the present invention can provide systems,
apparatus, and methods for authorizing a transaction initiated by a
consumer. In one embodiment, a likelihood function approximates a
pattern of previous transactions and provides a measure of how
likely it is for a transaction to occur as a function of time. The
time of a current transaction can be used to determine a
corresponding likelihood value of a likelihood function associated
with the transaction. The likelihood value can be used to determine
a score for authorizing the transaction. As the likelihood
corresponds to a particular time of a pattern, the score can be
tailored to the current transaction and achieve greater
accuracy.
[0008] According to one embodiment, a method of determining
authorization of a transaction involving a consumer is provided.
Data associated with the transaction is received. The data includes
a time T of the transaction. A likelihood function associated with
the consumer and with the transaction is identified. The likelihood
function approximates one or more patterns of previously performed
transactions. Also, the likelihood function has a respective
likelihood value for each of a plurality of times. A computer
system determines a first likelihood value of the likelihood
function, where the first likelihood provides a measure of a
likelihood of a transaction occurring at the time T. A score is
determined using the likelihood value and is adapted to be used to
determine authorization of the transaction.
[0009] According to another embodiment, data associated with the
transaction is received. One or more tables are identified as being
associated with the consumer and with the transaction. Each table
includes a plurality of values organized along at least one axis. A
first axis of each table corresponds to a plurality of different
time ranges. The values in each table correspond to a number of
previous transactions occurring within one of the different time
ranges. A computer system determines at least one value from each
table, where the at least one value is for a time range in which
the time T corresponds. A score is determined using the at least
one value and adapted to be used to determine authorization of the
transaction.
[0010] Other embodiments of the invention are directed to systems,
portable consumer devices, and computer readable media associated
with methods described herein.
[0011] A better understanding of the nature and advantages of the
present invention may be gained with reference to the following
detailed description and the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
[0012] FIG. 1 shows a block diagram of a system according to an
embodiment of the invention.
[0013] FIGS. 2A and 2B shows plots of transaction history of a
consumer as analyzed according to embodiments of the present
invention.
[0014] FIG. 3 is a flowchart of a method for authorizing a
transaction of a consumer according to embodiments of the present
invention.
[0015] FIG. 4 is a plot of a number of transactions at certain
elapsed times between a final transaction (with key KF) and an
initial event (with key KI) of a correlated key pair according to
embodiments of the present invention.
[0016] FIG. 5A shows a table for use in determining a periodic
probability function that approximates a pattern of transactions
according to an embodiment of the present invention.
[0017] FIG. 5B shows a plot for use in determining a number of
columns (buckets) of time or frequency to separate the previous
transactions according to an embodiment of the present
invention.
[0018] FIG. 6 shows an example of obtaining indicia of a similarity
of transactions of one entity relative to a transaction pattern of
another entity according to embodiments.
[0019] FIG. 7 shows a calculation of a likelihood that transaction
patterns of a first entity are similar to transaction patterns of a
second entity according to embodiments.
[0020] FIG. 8 is a flowchart of a method for determining a
likelihood of events for which data has been received according to
embodiments.
[0021] FIG. 9 shows a block diagram of an example computer system
usable with systems and methods according to embodiments of the
present invention.
DETAILED DESCRIPTION
[0022] Detecting fraud can save a lot of money in lost revenue.
However, current methods are not accurate and/or are slow.
Embodiments can provide systems, apparatus, and methods for
authorizing a transaction initiated by a consumer. In one
embodiment, a likelihood function approximates a pattern of
previous transactions and provides a measure of how likely it is
for a transaction to occur as a function of time. The time of a
current transaction can be used to determine a corresponding
likelihood value of a likelihood function associated with the
transaction. The likelihood value can be used to determine a score
for authorizing the transaction. As the likelihood corresponds to a
particular time of a pattern, the score can be tailored to the
current transaction and achieve greater accuracy.
[0023] I. System Overview
[0024] FIG. 1 shows an exemplary system 20 according to an
embodiment of the invention. Other systems according to other
embodiments of the invention may include more or less components
than are shown in FIG. 1.
[0025] The system 20 shown in FIG. 1 includes a merchant 22 and an
acquirer 24 associated with the merchant 22. In a typical payment
transaction, a consumer 30 may purchase goods or services at the
merchant 22 using a portable consumer device 32. The merchant 22
could be a physical brick and mortar merchant or an e-merchant. The
acquirer 24 can communicate with an issuer 28 via a payment
processing network 26. The merchant 22 could alternatively be
connected directly to the payment processing network 26. The
consumer may interact with the payment processing network 26 and
the merchant through an access device 34.
[0026] As used herein, an "acquirer" is typically a business
entity, e.g., a commercial bank that has a business relationship
with a particular merchant or an ATM. An "issuer" is typically a
business entity (e.g., a bank) which issues a portable consumer
device such as a credit or debit card to a consumer. Some entities
can perform both issuer and acquirer functions. Embodiments of the
invention encompass such single entity issuer-acquirers.
[0027] The consumer 30 may be an individual, or an organization
such as a business that is capable of purchasing goods or services.
In other embodiments, the consumer 30 may simply be a person who
wants to conduct some other type of transaction such as a money
transfer transaction or a transaction at an ATM.
[0028] The portable consumer device 32 may be in any suitable form.
For example, suitable portable consumer devices can be hand-held
and compact so that they can fit into a consumer's wallet and/or
pocket (e.g., pocket-sized). They may include smart cards, ordinary
credit or debit cards (with a magnetic strip and without a
microprocessor), keychain devices (such as the Speedpass.TM.
commercially available from Exxon-Mobil Corp.), etc. Other examples
of portable consumer devices include cellular phones, personal
digital assistants (PDAs), pagers, payment cards, security cards,
access cards, smart media, transponders, and the like. The portable
consumer devices can also be debit devices (e.g., a debit card),
credit devices (e.g., a credit card), or stored value devices
(e.g., a stored value card).
[0029] The merchant 22 may also have, or may receive communications
from, an access device 34 that can interact with the portable
consumer device 32. The access devices according to embodiments of
the invention can be in any suitable form. Examples of access
devices include point of sale (POS) devices, cellular phones, PDAs,
personal computers (PCs), tablet PCs, handheld specialized readers,
set-top boxes, electronic cash registers (ECRs), automated teller
machines (ATMs), virtual cash registers (VCRs), kiosks, security
systems, access systems, and the like.
[0030] If the access device 34 is a point of sale terminal, any
suitable point of sale terminal may be used including card readers.
The card readers may include any suitable contact or contactless
mode of operation. For example, exemplary card readers can include
RF (radio frequency) antennas, magnetic stripe readers, etc. to
interact with the portable consumer devices 32.
[0031] The access device 34 may also be a wireless phone. In one
embodiment, the portable consumer device 32 and the access device
are the same device. For example, a consumer may use a wireless to
phone to select items to buy through a browser.
[0032] When the access device 34 is a personal computer, the
interaction of the portable consumer devices 32 may be achieved via
the consumer 30 or another person entering the credit card
information into an application (e.g. a browser) that was opened to
purchase goods or services and that connects to a server of the
merchant, e.g. through a web site. In one embodiment, the personal
computer may be at a checkout stand of a retail store of the
merchant, and the application may already be connected to the
merchant server.
[0033] The portable consumer device 32 may further include a
contactless element, which is typically implemented in the form of
a semiconductor chip (or other data storage element) with an
associated wireless transfer (e.g., data transmission) element,
such as an antenna. Contactless element is associated with (e.g.,
embedded within) portable consumer device 32 and data or control
instructions transmitted via a cellular network may be applied to
contactless element by means of a contactless element interface
(not shown). The contactless element interface functions to permit
the exchange of data and/or control instructions between the mobile
device circuitry (and hence the cellular network) and an optional
contactless element.
[0034] The portable consumer device 32 may also include a processor
(e.g., a microprocessor) for processing the functions of the
portable consumer device 32 and a display to allow a consumer to
see phone numbers and other information and messages.
[0035] If the portable consumer device is in the form of a debit,
credit, or smartcard, the portable consumer device may also
optionally have features such as magnetic strips. Such devices can
operate in either a contact or contactless mode.
[0036] Referring again to FIG. 1, the payment processing network 26
may include data processing subsystems, networks, and operations
used to support and deliver authorization services, exception file
services, and clearing and settlement services. An exemplary
payment processing network may include VisaNet.TM.. Payment
processing networks such as VisaNet.TM. are able to process credit
card transactions, debit card transactions, and other types of
commercial transactions. VisaNet.TM., in particular, includes a VIP
system (Visa Integrated Payments system) which processes
authorization requests and a Base II system which performs clearing
and settlement services.
[0037] The payment processing network 26 may include a server
computer. A server computer is typically a powerful computer or
cluster of computers. For example, the server computer can be a
large mainframe, a minicomputer cluster, or a group of servers
functioning as a unit. In one example, the server computer may be a
database server coupled to a Web server. The payment processing
network 26 may use any suitable wired or wireless network,
including the Internet.
[0038] As shown in FIG. 1, the payment processing network 26 may
comprise a server 26a, which may be in communication with a
transaction history database 26b. In various embodiments, a
transaction analyzer 26c can determine patterns in transactions
stored in transaction history database 26b to determine certain
actions, such as authorizing a transaction or sending an incentive.
In one embodiment, an incentive system 27 is coupled with or part
of payment processing network 26 and can be used to determine an
incentive based on determined transaction patterns. Each of these
apparatus can be in communication with each other. In one
embodiment, all or parts of transaction analyzer 26c and/or
transaction history database 26b may be part of or share circuitry
with server 26a.
[0039] The issuer 28 may be a bank or other organization that may
have an account associated with the consumer 30. The issuer 28 may
operate a server which may be in communication with the payment
processing network 26.
[0040] Embodiments of the invention are not limited to the
above-described embodiments. For example, although separate
functional blocks are shown for an issuer, payment processing
network, and acquirer, some entities perform all or any suitable
combination of these functions and may be included in embodiments
of invention. Additional components may also be included in
embodiments of the invention.
[0041] II. Identifying Patterns
[0042] Consumer activity can include transactions, among other
things. Knowledge of a pattern of transactions of a consumer can
allow better fraud detection and other risk analysis by providing
greater accuracy in determining whether to authorize a transaction.
However, the identification of a pattern can be difficult given the
enormous amount of data, some of which might exhibit patterns and
some of which may not.
[0043] As used herein, the term "pattern" refers broadly to a
behavior of any set of events (e.g. transactions) that have a
likelihood of repeating. In one aspect, the likelihood can be
greater than a random set of events, e.g., events that are
uncorrelated. The likelihood can be expressed as a probability
(e.g. as a percentage or ratio), a rank (e.g. with numbers or
organized words), or other suitable values or characters. One type
of pattern is a frequency-based pattern in which the events repeats
with one or more frequencies, which may be predefined. To define a
pattern, a reference frame may be used. In various embodiments, the
reference frame may be or include an elapsed time since a last
event (e.g. of a type correlated to the current event), since a
beginning of a fixed time period, such as day, week, month, year, .
. . (which is an example of a starting event), before an end of a
fixed time period, or before occurrence of a scheduled event (an
example of an ending event). Another event can be certain actions
by the consumer, such as traveling to a specific geographic
location or browsing a certain address location on the
Internet.
[0044] FIG. 2A shows a plot 200 of a transaction history or other
events of a consumer as analyzed according to embodiments of the
present invention. Plot 200 shows times at which each of a
plurality of previous transactions 210 have occurred. As shown,
time is an absolute time (e.g. date and time) or an elapsed time
since an initial event 203. Herein, the term "time" can refer to
either or both a date and a time of a particular day. These
previous transactions 210, which occur before an end time 205, can
be analyzed to determine a pattern 220, which can be a function
that approximates when the transactions are likely to occur. As an
example, an identified pattern can be used to authorize a current
transaction, e.g. transaction 230.
[0045] The identification of a pattern can have many difficulties.
If the previous transactions 210 include all of the transactions of
a consumer and exhibit only one pattern, then the identification of
a pattern may be relatively easy. However, if only certain types of
transactions for a consumer show a pattern, then the identification
can be more difficult. Some embodiments can use keys (K1, K2, . . .
) to facilitate the analysis of certain types of transactions,
where a key can correspond to a type of transaction. The keys also
allow identification of transactions as being relevant for a
current task (e.g. associated with a current transaction).
[0046] For example, assume that FIG. 2A shows all of the
transactions with key K1 (i.e. each of the transactions have the
same key). A pattern analyzer can obtain time information by making
a query for transactions only with K1 (or as another example a key
pair <K1:K1>, as described below). The time information could
be stored as a list of the transactions in chronological order. The
occurrences of K1 transactions can then be analyzed (e.g. Fourier
analysis or other functional analysis) to identify a pattern of the
times and dates of these transactions. As shown, the transactions
are modeled with a periodic function (such as a sine or cosine),
which approximates the occurrences of the transactions. Parameters
of the function(s) can be modified until a good approximation of
the transactions occurring at peaks of the function(s). As shown,
pattern 220 exhibits a relatively long wavelength with groups of
transactions at the peaks of the pattern.
[0047] Adding to the complexity can be whether the path to a
particular transaction has an impact on the pattern, e.g., a
pattern that exists only when certain transactions precede or
follow a transaction. Embodiments can store transaction data
associated with a specific order of keys (e.g. K1, K3). In this
manner, the data for that specific order can be analyzed to
determine the pattern. The order of keys also allows the further
identification of relevant transactions.
[0048] All of this complexity can be further compounded in
instances where a certain path (sequence of two or more
transactions) can have more than one pattern. Embodiments can use
certain functional forms to help identify different patterns. In
some embodiments, periodic functions are used, e.g., e.sup.-iwt,
where w is a frequency of the pattern. In one embodiment, the
frequencies are pre-selected thereby allowing an efficient
determination of the patterns. Further, the frequencies can be
identified by an associated wavelength, or wavelength range.
Counters can be used for each wavelength range, thereby allowing a
pattern to be very quickly identified by analyzing the values of
the counters.
[0049] As an example of a different pattern, FIG. 2B shows a plot
250 of previous transactions 260 of a consumer as analyzed
according to embodiments of the present invention. Assume plot 250
only shows K2 transactions. Time data only for K2 transactions can
be identified as the specific time data can be stored associated
with the key K2. Thus, a pattern 270 of previous K2 transactions
can be identified by analyzing only the K2 transactions. Current
transactions 280 can then be analyzed in view of pattern 270. If
both previous transactions 210 and 260 were analyzed as a single
set of previous transactions for a consumer, the different patterns
220 and 270 would be harder to identify. Other more efficient
methods of determining patterns are discussed later.
[0050] III. Authorization of a Transaction
[0051] It is advantageous to authorize a transaction quickly while
maintaining an accurate risk assessment of the transaction, e.g.
via an authorization process. As mentioned above, once a pattern
has been determined, a transaction can be predicted to occur, e.g.,
in a specific time window. Knowing when transactions tend to occur
can allow an accurate determination of whether to authorize a
transaction when one does occur. For example, if an authorization
request is received for a current transaction at a time when the
transaction generally occurs, it is more likely that the
transaction is being initiated by the consumer.
[0052] FIG. 3 is a flowchart of a method 300 for authorizing a
transaction of a consumer according to embodiments. In one
embodiment, previous transactions (e.g. 210) are used to determine
if a current transaction is to be authorized. In one
implementation, transactions within a specific time period are
analyzed, e.g., last year or all transactions before the current
transaction. The transactions can also be filtered based on certain
criteria, such that only certain types of transactions are
analyzed. The transaction history can include valid and fraudulent
transactions. All or parts of method 300 or other methods herein
can be performed by a computer system that can include all or parts
of network 26; such a system can include disparate subsystems that
can exchange data, for example, via a network, by reading and
writing to a same memory, or via portable memory devices that are
transferred from one subsystem to another.
[0053] In step 310, data associated with transactions previously
performed, e.g. by the consumer or other similar consumers (an
affinity group), is received. For example, the data in the
transaction history database 26(b) can be received at a transaction
analyzer 26(c) of system 20 in FIG. 1, which includes a processor
that may be configured with software. Each transaction can have any
number of pieces of data associated with it. For example, the data
may include categories of an account number, amount of the
transaction, a time and date, type or name of product or service
involved in the transaction, merchant name or code (mcc), industry
code, terminal field (whether a card is swiped), and geographic
location (country, zip code, . . . ). In one embodiment, a merchant
could be a whole chain or a particular store of a chain. In some
embodiments, the transaction data can also include video and/or
audio data, e.g., to identify a person or a behavior of a person.
The transaction data can be different for each transaction,
including the account number. For example, the consumer can be
identified with the account number and other account numbers of the
consumer can be included in the analysis of the behavior of the
consumer.
[0054] This data can be used to identify a particular type of
transaction. In one embodiment, the data for a transaction is
parsed to identify one or more keys, which are used as identifiers
for a particular transaction. In various embodiments, a key can
includes parts of the transaction data and/or data derived from the
transaction data. A key could also be composed of results from an
analysis of a transaction, e.g., whether the transaction is a
card-present transaction or a card-not-present transaction could be
determined from the transaction data and included in the key. In
one embodiment, a mapping module can perform the mapping of the
transaction data to one or more keys.
[0055] A key can be composed of multiple pieces of data (referred
to herein as a key element). A longer key has more key elements and
may be a more selective identifier of a type of transactions. Each
transaction can be associated with different keys, each with a
different scope of specificity for characterizing the
transaction.
[0056] In step 320, transactions are optionally correlated with
other transactions and events. In this manner, different
transaction patterns can be identified for different types of
transactions. Other events (e.g. start or end of a day, week, etc.)
can be correlated to transactions as well. An event can also be a
movement of the consumer from one state to another (e.g. from an
at-home state to an on-vacation state). Different events can also
be identified with keys. Herein, examples are used to described how
keys are used to identify transaction types, but other suitable
methods can be used.
[0057] In one embodiment, pairs of correlated keys (e.g. a key pair
<KI:KF>) are determined based on whether transactions
associated with an initial key (KI) are correlated with
transactions with a final a final key (KF). A first (initial) event
can be correlated with a later (final) transaction. The initial key
and the final key may be the same or different from each other. For
example, a transaction at one merchant may be correlated to a later
purchase at another merchant, which might occur if the merchants
are near to each other. In one embodiment, a group of more than two
keys could be correlated together, e.g. a group of three keys can
be correlated.
[0058] Two transactions can be correlated in multiple ways
depending on how many keys are associated with each transaction.
Thus, two transactions can contribute to more than one key pair,
when the transactions are associated with multiple keys. For
example, if an initial transaction is associated with two keys and
the final transaction is also associated with two keys, then there
could be four resulting key pairs. Also, a transaction may be
correlated to another transaction only via certain keys.
[0059] In step 330, likelihood function(s) that approximate one or
more patterns of when the previous transactions occur are created.
In one embodiment, the likelihood functions of when the previous
transactions occur are determined with a computer system, e.g., the
transaction analyzer 26(c), which can be a subsystem or one
apparatus. The likelihood function(s) can convey the likelihood of
a transaction as a function of time and can include contributions
from multiple patterns, or just one pattern. For example, pattern
function 220 can be considered a likelihood function, and a
combination of pattern functions 220 and 270 can be considered a
likelihood function. In these examples, transactions are more
likely when the function has a higher value, and thus more likely
to lead to authorization. In other embodiments (described in more
detail below), a higher value can be less likely to lead to
authorization, e.g., when the pattern is of fraudulent
transactions.
[0060] In one embodiment, pairs of correlated transactions (or
other events) are used to determine a pattern, e.g., as times of
final transactions related to initial events. The times can be
stored as an absolute time and/or date for each transaction (e.g.
in chronological order) or organized as elapsed times for
correlated events of certain key pairs. The elapsed time may be the
time between a transaction with K1 and the next transaction with K2
for the correlated <K1:K2> pair. Other data can be stored as
well, e.g. data not included in the keys, such as an amount of the
transaction. The elapsed time can effectively equal an absolute
time if the initial event is the beginning of a time period.
[0061] In some embodiments, the time information is stored (e.g. in
transaction history database 26b) associated with the corresponding
key pair. For example, a key pair identifier (e.g. a unique ID
number) can be associated with the stored time information. As
examples of an association, a key pair identifier could point to
the time information, the time information could be stored in a
same row as the key pair identifier, and the key pair identifier
could be stored associated with the pointer.
[0062] In other embodiments, the time information for the key pair
<K1:K2> can be stored in a database table that can be
accessed with a query containing K1, K2, or the combination
(potentially in the order of K1:K2). For example, a search for K1
and/or K2 can provide the associated identifiers. In one
embodiment, a hash of each key of a pair is also associated with
the key pair identifier, so that information for each key can be
indexed and found separately. For example, hashes of K1 and K2 can
be stored in a lookup table so the key pair identifiers (and thus
the key pair information) can be easily found. A key pair table is
an example of a likelihood function, or a group of likelihood
functions, as the case may be.
[0063] In one aspect, storing time information in association with
certain key pairs can allow the time information for specific types
of transactions to be easily accessed. Also, such organization can
provide easier analysis of the data to identify patterns for
specific key pairs. The occurrences of the transaction can then be
analyzed (e.g. Fourier analysis or other functional analysis) to
identify a pattern of the times and dates of these
transactions.
[0064] In step 340, data for a transaction at time T is received.
In one embodiment, the transaction is a pending transaction that
has not yet completed. As an example, payment processing network 26
can receive the data as part of an authorization request from a
merchant. Payment processing network 26 can then perform a
procedure to aid in the determination of whether to authorize this
current transaction, e.g., by calculating a risk score or other
score.
[0065] In step 350, relevant likelihood function(s) are determined.
The relevant likelihood function(s) can be determined based on
whether a likelihood function and the transaction data share
matching values. In one embodiment, the matching can be performed
using keys. For example, relevant key pairs can be selected, and
tables or other data for a key pair can be obtained. In some
embodiments, to determine whether to authorize the transaction
(e.g., current transaction 230 in FIG. 2A), the relevant keys pairs
are all or some of the pairs that include keys that match a key
associated with the transaction. In one embodiment, the relevant
key pairs are all of the key pairs that are associated with the
current transaction as a final key. In another embodiment, the
relevant likelihood function(s) can be for patterns of other
entities, such as certain demographics or fraudulent patterns.
[0066] In step 360, one or more likelihood values of a relevant
likelihood function(s) at time T are determined. In one embodiment,
the likelihood values can be obtained from the tables for the
relevant key pairs. In various embodiments, the likelihood value
can be a number of transactions in a time range in which time T
falls within, the probability of a continuous function at time T
(e.g., as calculated from a value of one or more pattern functions
at time T), or other measure related to likelihood.
[0067] In an embodiment where a current transaction has multiple
keys associated with it, multiple likelihood values can be summed.
For example, assume that a current transaction has both keys K1 and
K2 associated with it. Thus, patterns 220 and 270 both might apply
to the transaction. The likelihood values for likelihood functions
of both these patterns can be summed, as the total likelihood for
the transaction is affected by both patterns. In one embodiment,
having a transaction associated with multiple keys can result in a
summing to determine overall likelihood, and separating out the
keys can allow the patterns to be more easily identified. In
another embodiment, the likelihood values are analyzed separately,
as mentioned below.
[0068] In step 370, the likelihood value(s) can be used to
determine a risk score or other score, which can be used to
determine whether to authorize a current transaction. In various
embodiments, the score can correspond to a likelihood that a
transaction is fraudulent, a likelihood that a transaction occurs
at a specific absolute or relative time, or a combination of
both.
[0069] In some embodiments, the likelihood value(s) can be input
into a modeling function as part of the determination of the score.
In various implementations, the modeling function can be an
optimization function (e.g. a neural network) or can be a decision
tree (e.g. composed of IF THEN logic that compares the likelihood
value(s) to one or more cutoff values). In one embodiment, an
optimization function can be trained on previous transactions, and
thus can determine whether a current event (e.g. a transaction)
fits previous patterns by a particular entity (e.g. a consumer or
merchant) to a sufficient degree to perform an action (e.g. the
authorization). The optimization algorithm can also be trained
using previous patterns from multiple entities (e.g. a fraud entity
or an affinity group). In another embodiment, the number of
associated keys associated with a current transaction relates to
the number of inputs into the modeling function. The relationship
is not necessarily one-to-one as similar keys (e.g. ones of a same
category) may be combined (e.g. same key elements, but just
different values), but there may be a correspondence between the
number of different types of keys and the number of inputs.
[0070] IV. Analysis of a Pattern
[0071] If a likelihood function for a pattern of when transactions
occur is known, then the likelihood function can be used to
determine a likelihood of a transaction occurring at a specific
time, and thus whether a current transaction at the specific time
should be authorized. For example, if a pattern (e.g. a pattern of
transactions associated with specific keys) for one or more
previous months is known, embodiments can use this pattern to
determine whether a current transaction fits that pattern, and
implicitly can conclude that the person initiating the transaction
is the owner of a particular account. The patterns can be analyzed
in numerous ways, and FIG. 4 describes some embodiments.
[0072] FIG. 4 is a plot 400 of a number of transactions at certain
elapsed times between a final transaction (with key KF) and an
initial event (with key KI) of a correlated key pair according to
embodiments. Plot 400 can be considered as a histogram. The X axis
is elapsed time between a final transaction and a correlated
initial event. Any unit of time may be employed, such as minutes,
hours, days, weeks, and even years. The Y axis is proportional to a
number of transactions. Each bar 410 corresponds to the number of
transactions at an elapsed time. Each bar 410 can increase over
time as new transactions are received, where a new transaction
would have an elapsed time relative to a correlated initial event.
Note that more than one transaction-event pair can have the same
elapsed time.
[0073] In one embodiment, the X axis can have discrete times. For
example, only transactions for each day may be tracked. Thus, if
the initial event was the start of a month, then the number of
discrete time periods would have a maximum of 31 days. In such an
embodiment, elapsed time values within a certain range can all
contribute to a same parameter, and bars 410 may be considered as
counters. For example, if the discrete times were by day, any two
transactions that have an elapsed time of 12 days since a
correlated KI event would both cause the same counter to be
increased. In one embodiment, these counters are the time
information that is stored as mentioned above. In some
implementations, the time ranges do not all have the same length.
For example, the time ranges closer to zero can have a smaller
length (e.g. just a few minutes) than the time ranges further from
zero (e.g. days or months).
[0074] A pattern 420 (an example of a likelihood function) can be
discerned from the elapsed times. As shown, pattern 420 has a
higher value at elapsed times where more transactions have
occurred. In one embodiment, pattern 420 could simply be the
counters themselves. However, in cases where the time intervals are
not discrete or have a small range, bars 410 might have zero or low
value at times that happen to lie between many transactions. In
these cases, certain embodiments can account for transactions at a
specific time as well as transactions at times that are close. For
example, as shown, a function representing the pattern of
transactions begins curving up and plateaus near the cluster 460 of
transactions to form a peak 430. In one embodiment, each time point
of the function can have a value of a moving average of the number
of transaction within a time period before and after (or just one
or the other) the time point. In other embodiments, function can be
determined from interpolation or other fitting method (e.g., a fit
to periodic functions) performed on the counters.
[0075] Indicia of the pattern 420, e.g., the function values, can
be analyzed to determine when a transaction is likely. In one
implementation, peaks of the pattern 420 are identified as
corresponding to times when a transaction is likely, and a time
window is determined from indicia of the peaks. In one embodiment,
a width of the function at specific values or times may then be
used as the time window. For example, a time window (e.g. a two day
or 1.5 day period) of when transactions often occur may be
determined (e.g. as may be done in 340).
[0076] The time window may be determined in any number of ways and
potentially with varied criteria. In one embodiment, a full width
at half maximum may be used, such as the width of peak 430. In
another embodiment, the window (e.g., 440) above a threshold value
450 is used, or just part of this window, e.g., starting at the
time where pattern 420 is above the threshold and ending at the top
(or other part) of peak 430. In yet another embodiment, the time
window may have a predetermined width centered or otherwise placed
(e.g. starting or ending) around a maximum or other value above a
threshold.
[0077] In embodiments using a threshold, the value of the pattern
function may be required to be above the threshold value before a
transaction is considered likely enough to authorize the
transaction. Multiple threshold levels can be used, with the
various levels potentially being used to determine a category of
how likely a transaction is. The category can then be used in a
determination of whether to authorize the transaction. The use of
thresholds encompass using the exact likelihood values, which can
be equivalent to using many threshold levels. The modeling function
mentioned above may be used to perform any of these
determinations.
[0078] In one embodiment, a threshold determination could be
whether a counter has a high enough value (absolute or relative to
one or more other counter). In another embodiment, a threshold
level can be relative (e.g. normalized) compared to a total number
of transactions. A normalization or determination of a threshold
can be performed by adjusting the level depending on the low values
of likelihood of a pattern, e.g., a peak to trough height could be
used. In one aspect, the troughs may be offset to zero.
[0079] Storing time information that includes a number of
transaction at certain elapsed times, one can not only handle paths
(such as initial key to final key), but one can also easily
identify multiple patterns. Each peak can correspond to a different
pattern. For example, each peak can correspond to a different
frequency of occurrence for a transaction associated with the final
key relative to an event (e.g. a transaction) associated with the
initial key. In one embodiment, the time information for the
elapsed times can be stored by storing a time of when both events
occur. In another embodiment, time information can store the
elapsed time as one value. In yet another embodiment, the time of
one event might implicitly include the time of the initial event
(e.g. when the first event is beginning of a month or other fixed
time period).
[0080] From FIG. 4, one can identify one predominant pattern (peak
430) with a long wavelength (short frequency), which does not occur
very often, and three minor peaks with higher frequencies. However,
the determination of a pattern might still take significant
computational effort if the pattern can have any functional
form.
[0081] V. Use of Periodic Functions and Counters
[0082] Some embodiments use certain functional forms to help
identify different patterns. As mentioned above, periodic functions
can be used, e.g., e.sup.iwt, where w is a frequency of the
pattern. For example, each bar (counter) 410 of FIG. 4 can
correspond to a different frequency. The total probability V of a
K2 transaction occurring at a time after a K1 transaction can be
considered as proportional to
W C w wt , ##EQU00001##
where C.sub.w corresponds to the counter value at the frequency w
and w runs over all of the frequencies. C.sub.w can be considered a
coefficient of the periodic function e.sup.iwt at a particular
frequency. Thus, conceptually, a probability can be calculated
directly from the above formula.
[0083] In one embodiment, the frequencies are pre-selected thereby
allowing an efficient determination of the patterns. Further, the
frequencies can be identified only by the associated wavelength, or
wavelength range. Note that in certain embodiments, the use of
e.sup.iwt is simply a tool and the actual value of the function is
not determined.
[0084] FIG. 5A shows a table 500 that stores time information for a
key pair <KI:KF> according to embodiments of the present
invention. The table 500 stores information for elapsed times
between transactions associated with the particular key pair. Table
500 can also store amount information for the transactions. Table
500 can be viewed as a tabular form of plot 400 along with all the
possible variations for different embodiments described for plot
400.
[0085] In one embodiment, each column 510 corresponds to a
different time range. The time range may correspond to ranges
mentioned above with reference to FIG. 4. As shown table 500 has 6
time ranges, but any number of time ranges may be used. The time
ranges can be considered to correspond to different functions that
approximate the transaction patterns of a consumer or other entity.
For example, each time range can correspond to or be considered a
different frequency w for e.sup.iwt.
[0086] In some embodiments, table 500 only has one row. In other
embodiments, the rows of table 500 correspond to different dollar
amounts (or dollar amount ranges). Thus, each time range may have
subgroups for set ranges of amounts (e.g. dollar amounts). The
organization is similar to a matrix, where a row or a column can be
viewed as a group or subgroup. Although five amount ranges are
shown, table 500 can have any number of dollar amounts. In some
embodiments, there is only one row. i.e. when dollar amounts are
not differentiated. Note that the convention of row and column is
used for ease of illustration, but either time or amount could be
used for either row or column (each an example of an axis). Also,
the data for a table can be stored in any manner, e.g. as a single
array or a two-dimensional array.
[0087] The values for the matrix elements 520 correspond to a
number of KF transactions that have elapsed times relative to a KI
event (e.g. a transaction) that fall within the time range of a
particular column 510. In one embodiment, each newly received K2
transaction can cause a box (element) 520 of the table (matrix) 500
to be increased. The value of the matrix element (an example of a
likelihood value) can be incremented by one for each transaction,
or another integer or non-integer value. The value can also be a
complex number, as described below. In another embodiment, a table
can be required to have a certain total of all values, average of
the values, minimum value in any matrix element, or other measure
of the values in the table. Such a requirement can ensure that
enough data has been received to provide an accurate pattern.
[0088] The values of the matrix elements can be used as likelihood
values of a pattern for the key pair <KI:KF>, e.g. as part of
step 330 of method 300. A combination of the matrix elements (e.g.
a row or a whole table) can be a likelihood function representing
one or more patterns. For example, matrix elements with high values
relative to the other matrix elements can indicate a pattern of
transactions in the corresponding time range, which can correspond
to a particular frequency w. In another embodiment, one could view
each matrix element in isolation to determine whether a transaction
is likely. For example, if a matrix element exceeds a threshold
value, it may be determined that a transaction is likely to occur
in that time range. The threshold can be determined in various
ways, for example, as a function of a sum of all of the matrix
elements, or equivalently can be fixed with the matrix elements
being normalized before a comparison to a threshold. Thus, step 360
can be accomplished easier based on how step 330 is done.
[0089] As mentioned above, the time ranges can all be of the same
length (e.g. 24 hours) or be of varying lengths. In one embodiment,
the first column is of very short time length, the second column is
of longer time length, and so on. In this manner, more detail is
obtained for short wavelengths while still allowing data to be
stored for long wavelengths without exhausting storage capacity. In
another embodiment, dollar amount ranges are progressively
structured in a similar manner as the time ranges can be. In one
implementation, the dollar amount range can be used to track the
likelihood of transactions having certain dollar amounts. A dollar
amount for a current transaction can be used to determine a
specific likelihood function that corresponds to the amount, e.g.,
a row of the table.
[0090] FIG. 5B shows a plot 510 for use in determining the time
ranges for table 500 according to an embodiment of the present
invention. The X axis corresponds to the column numbers. The Y axis
corresponds to the time of a particular column in minutes. For
example, the first column includes times between the first data
point at time domain zero and the data point at time domain 1. Due
to the large scale of the Y axis, the second data point appears to
be at zero, but is simply quite small relative to the maximum
value.
[0091] The wavelength .lamda. of a pattern corresponds to the time
range of a column. For embodiments, using time relative to another
transaction, then the .lamda. is the time between transactions. In
one embodiment, 16 time domains (ranges) are selected as follows:
.lamda..sub.0 is under 1 minute, .lamda..sub.1 is between 1 minute
and 2.7 minutes, .lamda..sub.2 is between 2.7 minutes and 7.4
minutes, .lamda..sub.3 is between 7.4 minutes and 20 minutes, and
.lamda..sub.15 is over 1.2 million minutes.
[0092] The amount values can also be used to determine patterns for
transactions of certain dollar amounts. If the amount is not of
concern, then the values in a column can be summed to get a total
value for a certain time range. The amounts can also be
incorporated into the mathematical concept introduced above. For
example, in mathematical notation, a value function can be defined
as
V = W C w A wt , ##EQU00002##
where A is an amount of a transaction.
[0093] When a transaction is received, the amount and corresponding
elapsed time for a particular key pair can be used to determine a
corresponding matrix element for the key pair table. The values in
the matrix elements can be normalized across one table and across
multiple tables. For example, a value can be divided by a sum for
all the values of a particular key pair table. Also, a sum can be
calculated for all values across multiple tables, and the values
for each table divided by this sum. As part of a normalization, the
value for a matrix element may be decreased when some of the data
used to determine the value becomes too old. For example, for a
time range that includes short time intervals, counts from
transactions that have occurred more than a year ago may be dropped
as being out of data since short timeframe patterns can change
quickly.
[0094] In various embodiments, tables for different key pairs can
have different time ranges and/or amount ranges. If such
differences do occur, the differences can be accounted when a
summing operation is performed. In one embodiment, the values in
the matrix elements can be smoothed to account for values in nearby
matrix elements, e.g., in a similar fashion as pattern 420.
[0095] In another embodiment, tables for different consumers can be
compared to determine affinity groups. For example, tables with
matching or similar key pairs can be subtracted (lower value more
similarity) or multiplied (higher value more similarity). The
closer the tables are, the more similarity (e.g. as a percentage)
the consumers are, where non-matching tables can be used for
normalization. In one example, one set of tables can correspond to
the affinity group, and the calculation can be used to determine
whether a person is within the affinity group.
[0096] In other embodiments, specific amount ranges or time ranges
can be suppressed. For example, if only certain types of patterns
(e.g. only certain frequencies) are desired to be analyzed, then
one can suppress the data for the other frequencies. In one
embodiment, the suppression is performed with a mask matrix that
has zeros in frequency columns and/or amount rows to be suppressed.
Thus, one can just multiply the matrices to obtain the desired
data. The amount ranges can be similarly suppressed. When
suppressing certain frequencies, these mask matrices can act
similarly to a high pass, low pass, or notch filters. For example,
if one wanted a coupon to be good only for 7 days, and it takes 1
day to create the coupon, the desired time window is any time range
that includes those 6 days. Accordingly, the time information for
transactions outside the time window can be suppressed as not being
of interest.
[0097] Regarding the creation and updating of such tables, after an
event (e.g. a consumer transaction) is received, embodiments can
determine which tracked key pairs have finals keys that match with
the keys resulting from the transaction. As a transaction can be
associated with many keys and key pairs, a transaction may cause
many tables to have a matrix element updated. For example, the
transaction may cause different tables for a specific consumer to
be updated. The updates could be for one table for all transactions
by that consumer (an example of a general table), and more specific
tables for particular zip codes, merchants, and other key elements.
The transaction can also cause updates of tables for the particular
merchant where the transaction occurred.
[0098] As there are different tables that can be updated, each with
a different initial key, the time range (and thus the matrix
element) that is updated may be different for each table. For
example, when elapsed time is used, the last transaction for each
table may be at a different elapsed time since the different
initial transactions. The transaction amount would typically be the
same, thus the exact row for the matrix element to be increased can
be the same, as long as the tables have the same amount ranges. But
the column (i.e. time) could be different for each table.
[0099] Regarding which time column to update, there can also be
more than one column updated for a particular table. For example, a
K2 transaction may have different time patterns relative to K1
transactions (i.e., <K1:K2> pair). Accordingly, when a K2
transaction is received, elapsed times from the last two, three, or
more K1 transactions could be used to update the table.
[0100] In a similar manner, one key pair table could be
<*:K2>, which includes correlations from a plurality of
initial keys to the K2 key in the same table. Effectively, this
table could equal the sum of all tables where K2 is the final key
for a particular consumer or other entity. However, if the
individual key pairs are not significant enough, the <*:K2>
table may be the only table that is tracked. Tables of the type
<K1:*> could also be tracked.
[0101] VI. Impedance (Likelihood of Another Transaction)
[0102] Besides being able to determine when a particular
transaction is likely, embodiments can also predict if another
transaction is going to occur after a current transaction, which is
referred to as impedance. In some embodiments, such information can
be tracked by using complex numbers for the matrix elements of the
final event, with the imaginary part corresponding to the
impedance. In other embodiments, the impedance can be tracked
simply using another number for a matrix element or using another
table. In one embodiment, impedance values can be used to determine
whether to authorize a transaction.
[0103] In such embodiments, the imaginary part of a matrix element
can correspond to an impedance that measures how likely it is that
another transaction will occur. Such values can be tracked for
individual consumers and/or groups of similar consumers (affinity
groups). The likelihood can specifically correspond to a future
transaction being correlated to the current transaction having the
time range and dollar amount of the matrix element. The real value
of a matrix element can correspond to the probability that the KF
event will occur, and the imaginary value can relate to the
probability that another event will be correlated to the KF event.
The imaginary part can be updated when another transaction is
correlated to the KF event of the specific time and amount. In one
embodiment, a table can have just one impedance value for the
likelihood of any transaction occurring later. Thus, just one
imaginary part could be stored for an entire table. In another
embodiment, the imaginary parts could be different for each matrix
element.
[0104] In an embodiment, a low impedance (e.g. a large negative
imaginary part) for a matrix element means that there is a high
probability that another transaction is going to occur, and a high
impedance (e.g. high positive value) means that it is unlikely that
another transaction is going to occur, with zero being
indeterminate. The implication of negative and positive values can
be swapped. In another embodiment, a high impedance is provided by
a low number (negative or positive), with larger numbers providing
low impedance, or vice versa. Certain future transactions can be
ignored (e.g. not counted) in determining impedance, for example,
if the dollar amount is too low.
[0105] In this way, one can determine the specific instances where
the transaction is a dead end (i.e. not leading to other
transactions), and other instances where the transaction leads to
other transactions. A high impedance would convey that the
transaction is a dead end as no further transactions occur very
often. Conversely, one can determine that a transaction is a
gateway to many other transactions when it has a low impedance. In
one embodiment, an average or sum of all of the imaginary parts of
the matrix elements can be used to determine whether any future
transaction is likely.
[0106] Instead of or in addition to the above use of imaginary
values for impedance, greater impedance can also correspond to
fraud. If a fraud transaction K2 is found to correlate to a
transaction K1, then the <KI:K1> matrix elements (or just a
specific element) can have the impedance increased. Thus, the
impedance can reflect the profitability of the present transaction.
For example, certain transactions happening right after buying a
concert ticket can be associated with fraud, which is an example of
where each matrix element may have its own complex part.
[0107] In some embodiments, both real and imaginary parts of a
matrix element can contribute to an overall value, which can be
used to determine whether to authorize a transaction. In other
embodiments, values for the real or the imaginary components can be
analyzed separately to determine whether a transaction is likely
and then determine whether to authorize based on values for fraud
or possible profit from following transactions.
[0108] VII. Calculation of Lieklihood Values
[0109] Once the relevant likelihood functions (e.g. key pair tables
resulting from a filtering process) are obtained, the likelihood
functions can be analyzed to provide likelihood values for specific
events. The calculation of the likelihood functions can be
performed in numerous ways. In one embodiment, the likelihood
values can include specific matrix elements corresponding to a
current transaction. The matrix elements can be modified (e.g.
normalized) and/or summed to provide an overall likelihood. In
another embodiment, the likelihood functions can be operated upon
(e.g. summed or added with other values). This section describes
some embodiments for obtaining relevant likelihood functions for an
event from certain event patterns. [0110] A. Determining Similarity
Of Transactions To Established Patterns
[0111] One likelihood of interest is whether a specific transaction
fits established transaction patterns of a consumer. Such a
likelihood can be used to authorize a current transaction. To
determine a likelihood, the current transaction can be compared to
established transaction patterns.
[0112] In an example where one or more recent transactions are
received, these recent transaction(s) can be compared to
established transaction patterns of the consumer or other entities
(e.g. fraudsters or a specific demographic). Such a comparison may
be done as part of a determination whether to authorize a recent
transaction. For example, if the transaction is similar to the
established patterns of the consumer, then there is a greater
likelihood of authorizing the transaction. Conversely, if the
recent transaction is similar to the long term patterns of a
fraudster, the likelihood of authorizing the transaction is less.
The established patterns can be created from previous transactions
that are known or assumed to be associated with a particular
entity.
[0113] In one embodiment, a time interval between a recent
transaction associated with a key KF and one or more other
transactions associated with a key KI can be determined. Using
methods described herein, one can obtain the <KI:KF> key pair
table, created from KF transactions that have previously been
correlated to KI transactions. For example, the keys KI and KF can
be used to query the established tables for a consumer to obtain
the <KI:KF> key pair table.
[0114] The time interval and potentially a dollar amount can then
be used to select the appropriate matrix element. This matrix
element, potentially along with the other matrix elements of the
retrieved matrices can provide a likelihood directly or in
combination with other values. For example, the matrix element can
be divided by a sum of matrix elements in a row, all matrix
elements in a table, or all transactions of a person to determine a
likelihood for the recent transaction. The appropriate matrix
element(s) can be selected using multiplication.
[0115] FIG. 6 shows an example of obtaining indicia of a similarity
of a recent transaction relative to an established transaction
pattern of a consumer according to embodiments. In FIG. 6, a
short-term table 610 created from one or more recent transactions
is multiplied (element by element) by pattern table 620 to provide
indicia 630, which can be used as a likelihood value. Indicia 630
can provide a measure of how similar the short-term table is to the
pattern table 620, and thus how likely that it is for the recent
transaction to have occurred.
[0116] In this simple example, suppose the recent transaction is
associated only with K1, and K1 is correlated only to K2. Then a
table <K2:K1> can be created with a "1" in the proper matrix
element of table 610 relative to the last K2 transaction, with
zeros in the other matrix elements. Table 610 shows a value of 1
for the first dollar amount and the fourth time range. Then,
short-term table 610 can multiply the <K2:K1> key pair table
620 (which has been matched and retrieved), with the result
selecting out the matrix element that matches the short-term matrix
element, in this case "2". The value of this matrix element 630 can
(e.g. when normalized) can provide a measure of a likelihood of the
K1 transaction at that specific time. Since "2" is relatively low
compared to the other matrix elements, the likelihood of the K2
transaction occurring with the specified dollar amount is
relatively low. Note that the likelihood can be determined only
based the matrix elements in the same row.
[0117] In another embodiment, pattern table 620 can correspond to a
pattern of fraud. Thus, the indicia 630 having a value of "2" this
can be seen as a low likelihood of fraud relative to the other
times. However, if the matrix element was the largest value in the
table, then the recent transaction K1 can be seen as having a
higher likelihood of fraud.
[0118] Overall, multiple short-term tables might result for a
current K1 transaction. Also, a single short-term table could have
multiple matrix elements with a "1" or other value to signify that
the time interval between transactions falls within the specified
time range. Multiple recent transactions may also be used to
determine the likelihood for the K1 transaction. For example, if
other recent transactions are not likely, then they may affect the
likelihood of the most recent transaction. Such use of other recent
transactions may be used in any embodiment. [0119] B. Multiplying
Tables--Alignment
[0120] There may be instances where the key pair for a short-term
table is not found in the key pairs of an established pattern
tables. When this occurs, a short-term table may be aligned with an
established pattern table to determine a matching table for
multiplying. In one embodiment, a key for the short-term table can
be broadened until a match occurs.
[0121] For example, a short-term table can have a final key of
:4812,345>, where 4812 is the merchant code and 345 is the first
three digits of a zip code. However, the tables of a second entity
may not contain a table with this final key. This may be because
the consumer has few transaction in zip codes starting with 345.
But the short-term table may still contain useful information as to
a similarity of the entities. Thus, the key :4812,345> can be
broadened to be :4812,*> so that it matches with a table of the
second entity. The zip code can be broadened in one step or
incrementally to :4812,34>, :4812,3>, and then :4812,*>,
where a match is found.
[0122] Such alignment can be performed between sets of key pair
tables. In a general sense, a set of key pair tables can be viewed
as a key manifold. When the key manifolds are normal (i.e. both
spaces have identical amounts of keys), then one can apply the
operations directly. However, if the key spaces are not normalized,
then an alignment may be performed.
[0123] In one embodiment, each table of one manifold is aligned
with exactly one table of the other manifold. In another
embodiment, there may not be a match found for a table from one
manifold to another. In such a case, the non-matching tables can be
dropped, or distinguished from tables that did match after
alignment. A distinction can also be made between tables that only
match after alignment and tables that match exactly. For example,
it may be useful to know what the entities do that is not the same
(no match), or maybe just similar (match after some alignment).
Also, other operations besides multiplication can be performed,
such as division, subtraction, and addition. [0124] C. Similarity
to Fraud
[0125] With this framework of aligning and multiplying keys, more
complicated calculations of likelihood can be performed. Other
operations, such as division can be used. A purpose of division can
be to normalize a key manifold (i.e. a set of tables).
[0126] FIG. 7 shows a calculation of a likelihood that a
transaction or set of transactions are similar to established
patterns according to embodiments. Such a calculation can provide a
likelihood of occurrence of a transaction. Fraud tables 710 and
total transaction tables 720 are established pattern tables, which
can be updated at set times, e.g., once a day, week, etc. Account
tables 730 are short-term tables created from the transaction or
set of transactions. The constants table 740 is a table that can be
used for normalizing, e.g., to place the values of a table to be
within a specific range.
[0127] Fraud tables 710 can be obtained from fraudulent
transactions across all or many entities. In one embodiment, the
specific set of tables have a common key element, e.g., all fraud
for a specific merchant or during a specific month. Other key
elements can be used, e.g., zip code, country, or any other
suitable key element. The fraud tables selected may be ones that
have a significant amount of fraud. For example, a transaction from
one zip code to another zip code far away within a short time frame
is likely to be fraud.
[0128] Total transactions tables 720 can be obtained from all
transactions across all or many entities. In one embodiment, the
total transactions tables 720 are obtained from the same entities
as the fraud tables 710. Similar to fraud tables 710, total
transactions tables 720 can share a same key element, for example,
the same key element as in fraud tables 710. The total transactions
can include fraudulent transactions and valid transactions, or just
valid transactions. The fraud and total transactions tables can be
computed in a batch at prescribed times, e.g., every day, week,
month. The number of fraud and/or total transaction tables can be
quite high, e.g., 10,000 to 500,000 or more.
[0129] In an example where the fraud tables 710 and the total
transactions tables 720 include transactions for a particular
month, there may be fewer fraud tables than total transaction
tables. This may occur since not all key pairs may have a
significant enough fraudulent transactions to have a certain key
pair table tracked. In such instances, the fraud tables that are
being tracked can be aligned with the total transaction tables.
[0130] Once the tables are aligned, the total transaction tables
720 can be used to normalize the fraud tables 710 by dividing a
fraud table by the corresponding total transaction table. After the
division, the normalized fraud tables can be stored in RAM (or any
other memory with faster access than disk). As with FIG. 9, the
division operation divides each matrix element of a fraud table
with the corresponding matrix element of the total transaction
table. The division can provide a normalization of the counters for
the fraud tables. For instance, a particular fraud table may have
high values, but if there are many total transactions, the total
percentage of transactions that are fraudulent is low. Thus, the
likelihood of a fraudulent transaction is low.
[0131] In one embodiment, each fraud table is aligned with exactly
one transaction table. For example, if there are 100 fraud tables
tracked (i.e. for a given group having a common element, such as
month), then 100 tables result from the alignment and division.
Note that the alignment can be implicit in the notation of a
division operation. In some embodiments, there may not be a match
of a fraud table to a total transaction table, although this may
happen rarely. In such a case, the fraud table may be dropped, and
thus there may be fewer resulting tables than fraud tables. In an
embodiment, one can differentiate fraud tables that do not have a
match from tables that did match, or between tables that only match
after alignment and tables that match exactly.
[0132] Account tables 730 can be created from a plurality of recent
transactions, e.g., as fraud tends to happen in bunches of
consecutive transactions. Regardless of how many recent
transactions are used, multiple account tables can result. For
example, one transaction can have a key that is correlated to
multiple initial keys. Thus, a plurality of short-term key pair
tables can be generated. An account table can have a form as
described above for table 910. In various embodiments, mapping
module 392 and/or a matching module (e.g. module 794) can be used
to determine which short-term key pair tables are created.
[0133] Account tables 730 can then aligned with the normalized
fraud tables. Before alignment, some or all of the account tables
can be summed. In one embodiment, two account tables can be summed
when the keys are similar. In effect, the final transactions for
each of the tables can be considered to be of a same type, i.e.
have the same key. For example, if the merchant is the same, but
the zip codes are different, the two tables can be merged and the
zip code dropped or broadened (which can be considered an
intersection of the two key pair tables). This summing may be
particularly appropriate when both tables would be aligned with a
same fraud table. In such a case, a summing after multiplying the
account tables by the normalized fraud tables provides the same
resulting table.
[0134] After alignment, the account tables can be multiplied
element-by-element with the normalized fraud tables, thereby
providing a plurality of account-fraud tables. In one embodiment,
these account-fraud tables can be summed to provide one final
table. In one aspect, the summing can be due to the fraud tables
710 being grouped to have a similar key element, and thus the final
table can relate to the one key element. This final table can
provide an overall similarity of the transaction patterns to
certain types of fraud, and therefore can be used (e.g. by a
modeling function as mentioned in step 380 of method 300) to
determine a likelihood of whether a transaction is actually from
the consumer. In another embodiment, each of the account-fraud
tables can independently be final tables that are used by a
modeling function.
[0135] In one embodiment, if an account table cannot be aligned
(i.e. there is no corresponding normalized fraud table), then an
average value of fraud can be used. In various embodiments, this
average level of fraud is single number that multiplies the account
table, is a table of average values, and can be the same across all
fraud groups or just the same within a single fraud group.
[0136] In another embodiment, a mask matrix can be used to remove
certain matrix elements from the account-fraud tables or from the
final table. For example, the mask matrix can remove low frequency
or high frequency components, or be a notch filter to select
frequencies in the middle. Also, certain dollar amounts can also be
removed. In one implementation, the mask matrix has 1s in matrix
elements that are to be kept and 0s in matrix elements that are not
to be analyzed.
[0137] Although fraud tables 710 were normalized, the final
table(s) may still have matrix elements with values that can vary
widely. This variation in values can cause instability in a
modeling function, which uses the matrix element as indicia of the
patterns to obtain a likelihood value. Accordingly, in some
embodiments, constants matrix 740 is used to constrain the final
matrix element to be within a certain range of values, e.g.,
between -1 and 1 or 0 and 1. In one embodiment, constants matrix
740 is created from a specified functional form, such as tanh, log,
or sigmoid (generally S shaped) functional form.
[0138] Constants matrix 740 can also constrain matrix elements
values to correspond to a third number within the prescribed range.
For example, a zero output can be mapped to a matrix element value
where fraud and valid transactions may be more difficult to
determine and thus sensitivity needs to be greater. In one
embodiment, the functional form of constants matrix 740 can be kept
for an extended period of time, where inputs of specific matrix
element values (e.g. maximum and minimum values in a specific
table) are used to determine the exact values. Which count
corresponds to zero may also have an input parameter. The
functional forms may be constant or vary across multiple
entities.
[0139] The calculation shown in FIG. 7 can done for different
groups of fraud tables, e.g. one group shares a same merchant, one
group shares a month, etc. In such embodiments, the account tables
used for a particular group can be chosen to correspond with a
particular group. Thus, different account tables can be used for
different groups. In one embodiment, each of these calculations can
then be combined and provided to a model function that uses the
inputs to determine a risk score related to whether the transaction
is fraudulent or not.
[0140] Instead of or in addition to the comparison to fraud, one
can also add a calculation involving the established transaction
pattern of a consumer. In such embodiments, the fraud tables can be
replaced with the established key pair tables of the consumer. The
multiplication operation can then provide a measure of how likely
the recent transactions fit the consumer's pattern, and thus can
contribute to a determination of whether a transaction is from the
consumer. A higher similarity to the established pattern can
signify a higher likelihood of the transaction being valid. The
final results from the fraud comparison and the consumer comparison
can be analyzed separately or both be input to a same modeling
function that accounts for the respective values.
[0141] The form of the formula in FIG. 7 can also be used to
determine how likely a consumer is part of an affinity group.
Instead of the fraud tables, the key pair tables of an affinity
group can be used. Normalization can still be performed with total
transaction tables for the specific affinity group or transaction
tables across multiple affinity groups. The account tables can
still be made of just recent transactions, or can be tables for
established patterns of a consumer. The tables can be normalized as
well.
[0142] In one embodiment, the normalized fraud tables (and
potentially the account tables) can be stored across multiple
processors and each one can perform the corresponding
multiplication if there is a match to an account table. As an
alternative, a query can be provided to each processor and the
processor that is storing the desired fraud table can return the
requested table. The final table(s) can be provided to a single
processor or set of processors that are configured to run a
modeling function.
[0143] VIII. Likelihood for a Current Transaction
[0144] As stated above, embodiments can be used to determine a
likelihood (e.g. a risk score) that an event (e.g. a transaction)
is fraudulent, a likelihood of an entity being similar to a
demographic, a likelihood of an event occurring, or any other
likelihood measure. FIG. 8 is a flowchart of a method 800 for
determining a likelihood of events for which data has been received
according to embodiments. Method 800 can be performed by any one,
plurality, or combination of computer apparatus described herein,
and components thereof.
[0145] In step 810, data for a pending transaction is received. The
pending transaction can be a transaction that has been initiated by
a consumer, but has not completed as authorization has not yet been
provided. In one embodiment, the transaction data is received as
part of an authorization request sent by a merchant. In another
embodiment, data for recent transactions are retrieved for
processing as well. These recent transactions may be used to
determine authorization of the pending transaction, for example, by
being used to determine if a fraud pattern is emerging and thus if
fraud for the pending transaction is more likely (e.g. as described
above for FIG. 7).
[0146] In step 820, the transaction data is used to map the pending
transaction to one or more keys. If recent transactions are used,
the recent transactions can also be mapped, or have been previously
mapped. In some embodiments, the mapped keys are specifically keys
that are being tracked, for example, for the consumer, an affinity
group, or a fraud entity. In one embodiment, the mapping is
performed by a mapping module, which can also ensure that the
mapped keys are specifically keys that are being tracked for a
particular entity.
[0147] In step 830, key pair tables (e.g. short-term tables 730)
are generated using the keys and time information of the
transactions. In one embodiment, the key pair tables have a final
key matching one of the keys resulting from step 820 are obtained.
In another embodiment, the key pair tables can be combined when two
transactions are similar. For example, similar zip code keys for
two transactions (e.g. one recent and the pending transaction) can
be combined into a single broader zip code key.
[0148] In step 840, tables of established patterns that correspond
to the generated key tables from step 830 are identified. These
tables can be likelihood functions that approximate patterns. The
corresponding tables may be associated with a same entity as the
key pair tables in step 830. For example, the corresponding tables
may be the established event patterns for a consumer. In other
embodiments, the corresponding tables are for an affinity group or
for a fraud entity, both of which are associated with the consumer
as entities whose patterns relate to determining whether to
authorize the transactions of a consumer. The corresponding tables
may be a combination of tables, e.g., fraud tables 710 divided by
total transaction tables 720. In one embodiment, a matching and
retrieval function identifies the relevant tables using methods
described herein. In another embodiment, an established pattern
table is required to have a certain total of all values, average of
the values, minimum value in any matrix element, or other measure
of the values in the table. Such a requirement can ensure that
enough data has been received to provide an accurate pattern.
[0149] In step 850, each generated key pair table is multiplied by
a corresponding established pattern table, thereby providing a
plurality of resulting tables. In one aspect, each matrix element
of one table is multiplied by a corresponding matrix element of the
other table. These resulting tables can be summed into one final
table, only some of the tables can be summed, or not summed. The
final table(s) can be multiplied by a table of constants to
transform the matrix element values to be within a predetermined
range of values. In one embodiment, the values of the resulting
tables can each be used as likelihood values. In another
embodiment, only the non-zero values of the resulting tables are
used as likelihood values.
[0150] In step 860, at least some of the values of the final tables
are used as input to a modeling function, such as an optimization
algorithm or a decision tree. In one embodiment, only the non-zero
values are entered into the modeling function. The matrix elements
of the final tables can be separately input to the modeling
function. The modeling function can analyze the final tables to
determine a score, such as a risk score for the event being fraud
or a similarity score for the generated key pair tables being
similar to the pattern tables (e.g. to see if a person is part of
an affinity group).
[0151] In step 870, the score is used to determine whether a
certain action is performed. For example, if a risk score is above
a certain value the event can be considered to valid, and not
fraud, or vice versa. A level of validity or fraud can depend on
the specific values of the score. The risk score by itself or other
factors can be used by an authorization entity (e.g. an issuer or a
payment processing network) to determine whether or not to
authorize the transaction. In embodiments where the score includes
a similarity to the transaction patterns of a consumer, a person
may be allowed to enter incorrect information (e.g. mistype a zip
code), but the system can still authorize the transaction when the
transaction fits established patterns. Some embodiments can even
have a requirement of entering the zip code to be actively removed
after a swipe of a card if the likelihood is sufficiently high. In
one embodiment, challenge questions can be determined based on a
value of the score.
[0152] Any of the computer systems mentioned herein may utilize any
suitable number of subsystems. Examples of such subsystems are
shown in FIG. 9 in computer apparatus 900. In some embodiments, a
computer system includes a single computer apparatus, where the
subsystems can be the components of the computer apparatus. In
other embodiments, a computer system can include multiple computer
apparatuses, each being a subsystem, with internal components.
[0153] The subsystems shown in FIG. 9 are interconnected via a
system bus 975. Additional subsystems such as a printer 974,
keyboard 978, fixed disk 979, monitor 976, which is coupled to
display adapter 982, and others are shown. Peripherals and
input/output (I/O) devices, which couple to I/O controller 971, can
be connected to the computer system by any number of means known in
the art, such as serial port 977. For example, serial port 977 or
external interface 981 can be used to connect computer system 900
to a wide area network such as the Internet, a mouse input device,
or a scanner. The interconnection via system bus 975 allows the
central processor 973 to communicate with each subsystem and to
control the execution of instructions from system memory 972 or the
fixed disk 979, as well as the exchange of information between
subsystems. The system memory 972 and/or the fixed disk 979 may
embody a computer readable medium. Any of the values mentioned
herein can be output from one component to another component and
can be output to the user.
[0154] A computer system can include a plurality of the same
components or subsystems, e.g., connected together by external
interface 981. In some embodiments, computer systems, subsystem, or
apparatuses can communicate over a network. In such instances, one
computer can be considered a client and another computer a server.
A client and a server can each include multiple systems,
subsystems, or components, mentioned herein.
[0155] The specific details of particular embodiments may be
combined in any suitable manner without departing from the spirit
and scope of embodiments of the invention. However, other
embodiments of the invention may be directed to specific
embodiments relating to each individual aspect, or specific
combinations of these individual aspects.
[0156] It should be understood that the present invention as
described above can be implemented in the form of control logic
using hardware and/or using computer software in a modular or
integrated manner. Based on the disclosure and teachings provided
herein, a person of ordinary skill in the art will know and
appreciate other ways and/or methods to implement the present
invention using hardware and a combination of hardware and
software
[0157] Any of the software components or functions described in
this application, may be implemented as software code to be
executed by a processor using any suitable computer language such
as, for example, Java, C++ or Perl using, for example, conventional
or object-oriented techniques. The software code may be stored as a
series of instructions, or commands on a computer readable medium
for storage and/or transmission, suitable media include random
access memory (RAM), a read only memory (ROM), a magnetic medium
such as a hard-drive or a floppy disk, or an optical medium such as
a compact disk (CD) or DVD (digital versatile disk), flash memory,
and the like. The computer readable medium may be any combination
of such storage or transmission devices.
[0158] Such programs may also be encoded and transmitted using
carrier signals adapted for transmission via wired, optical, and/or
wireless networks conforming to a variety of protocols, including
the Internet. As such, a computer readable medium according to an
embodiment of the present invention may be created using a data
signal encoded with such programs. Computer readable media encoded
with the program code may be packaged with a compatible device or
provided separately from other devices (e.g., via Internet
download). Any such computer readable medium may reside on or
within a single computer program product (e.g. a hard drive, a CD,
or an entire computer system), and may be present on or within
different computer program products within a system or network. A
computer system may include a monitor, printer, or other suitable
display for providing any of the results mentioned herein to a
user.
[0159] The above description of exemplary embodiments of the
invention has been presented for the purposes of illustration and
description. It is not intended to be exhaustive or to limit the
invention to the precise form described, and many modifications and
variations are possible in light of the teaching above. The
embodiments were chosen and described in order to best explain the
principles of the invention and its practical applications to
thereby enable others skilled in the art to best utilize the
invention in various embodiments and with various modifications as
are suited to the particular use contemplated.
* * * * *