U.S. patent application number 16/448884 was filed with the patent office on 2019-12-26 for systems and methods for authenticating online users in regulated environments.
The applicant listed for this patent is MASTERCARD INTERNATIONAL INCORPORATED. Invention is credited to Paul Baker, Robert Albert Ederle, Felix Johannes Flory, Julia Sharon Gosset, Nimit Gulati, Ranjita Shankar Iyer, Christopher John Merz, Brian Piel.
Application Number | 20190392450 16/448884 |
Document ID | / |
Family ID | 68980633 |
Filed Date | 2019-12-26 |
![](/patent/app/20190392450/US20190392450A1-20191226-D00000.png)
![](/patent/app/20190392450/US20190392450A1-20191226-D00001.png)
![](/patent/app/20190392450/US20190392450A1-20191226-D00002.png)
![](/patent/app/20190392450/US20190392450A1-20191226-D00003.png)
![](/patent/app/20190392450/US20190392450A1-20191226-D00004.png)
![](/patent/app/20190392450/US20190392450A1-20191226-D00005.png)
![](/patent/app/20190392450/US20190392450A1-20191226-D00006.png)
![](/patent/app/20190392450/US20190392450A1-20191226-D00007.png)
![](/patent/app/20190392450/US20190392450A1-20191226-D00008.png)
![](/patent/app/20190392450/US20190392450A1-20191226-D00009.png)
![](/patent/app/20190392450/US20190392450A1-20191226-D00010.png)
View All Diagrams
United States Patent
Application |
20190392450 |
Kind Code |
A1 |
Gosset; Julia Sharon ; et
al. |
December 26, 2019 |
SYSTEMS AND METHODS FOR AUTHENTICATING ONLINE USERS IN REGULATED
ENVIRONMENTS
Abstract
An authentication platform for authenticating an online user in
a transaction without use of strong consumer authentication (SCA)
includes receiving an authentication request message for a
transaction involving a regulated market includes authentication
data and a transaction value, extracting the authentication data
from the authentication request message, generating risk-based
authentication (RBA) result data, determining that a risk of fraud
in the transaction satisfies a risk threshold established by the
regulatory entity by evaluating the risk score relative to the risk
threshold, determining that the transaction value is below a
transaction limit set by the regulatory entity, the transaction
limit identifies a threshold transaction value below which strong
consumer authentication may be avoided for transactions satisfying
the risk threshold, and transmitting an authentication response
message authenticating the transaction without strong consumer
authentication having been performed based on satisfying the risk
threshold and being below the transaction limit.
Inventors: |
Gosset; Julia Sharon;
(Tarrytown, NY) ; Ederle; Robert Albert;
(Chesterfield, MO) ; Iyer; Ranjita Shankar;
(Chappaqua, NY) ; Piel; Brian; (Ballwin, MO)
; Merz; Christopher John; (Wildwood, MO) ; Flory;
Felix Johannes; (Wildwood, MO) ; Gulati; Nimit;
(Singapore, SG) ; Baker; Paul; (Shipley,
GB) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
MASTERCARD INTERNATIONAL INCORPORATED |
Purchase |
NY |
US |
|
|
Family ID: |
68980633 |
Appl. No.: |
16/448884 |
Filed: |
June 21, 2019 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
62688528 |
Jun 22, 2018 |
|
|
|
62688529 |
Jun 22, 2018 |
|
|
|
62688546 |
Jun 22, 2018 |
|
|
|
62688532 |
Jun 22, 2018 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04L 2463/082 20130101;
G06Q 20/4016 20130101; H04L 63/101 20130101; H04L 63/1425 20130101;
H04L 63/0853 20130101; H04L 63/102 20130101; H04L 63/08 20130101;
G06Q 20/12 20130101; G06Q 20/401 20130101; H04L 63/083 20130101;
G06Q 20/388 20130101; G06Q 20/405 20130101; H04L 63/108 20130101;
G06Q 20/40 20130101; G06Q 20/3226 20130101; H04W 12/00505
20190101 |
International
Class: |
G06Q 20/40 20060101
G06Q020/40; G06Q 20/12 20060101 G06Q020/12; H04L 29/06 20060101
H04L029/06 |
Claims
1. An authentication platform for authenticating an online user in
a transaction without use of strong consumer authentication (SCA),
the authentication platform comprising: a memory device; and at
least one processor coupled to the memory device, the at least one
processor programmed to: receive an authentication request message
for a transaction involving a market regulated by a regulatory
entity, the authentication request message includes authentication
data and a transaction value; extract the authentication data from
the authentication request message; generate, based at least in
part on the extracted authentication data, risk-based
authentication (RBA) result data that includes a risk score for the
transaction; determine that a risk of fraud in the transaction
satisfies a risk threshold established by the regulatory entity by
evaluating the risk score relative to the risk threshold; determine
that the transaction value is below a transaction limit set by the
regulatory entity, the transaction limit identifies a threshold
transaction value below which strong consumer authentication may be
avoided for transactions satisfying the risk threshold; and
transmit an authentication response message authenticating the
transaction without strong consumer authentication having been
performed on the transaction based on the determined risk of fraud
satisfying the risk threshold and further based on the determined
transaction amount being below the transaction limit.
2. The authentication platform of claim 1, the processor is further
configured to: generate an enhanced authentication request message
associated with the transaction, the enhanced authentication
request message including data indicating that the transaction is
not mandated for strong consumer authentication; and transmit the
enhanced authentication request message to an access control server
(ACS).
3. The authentication platform of claim 2, the processor is further
configured to: generate another enhanced authentication request
message associated with another transaction, the other enhanced
authentication request message including data indicating that the
transaction is mandated for strong consumer authentication; and
transmit the other enhanced authentication request message to an
access control server, the indicated mandate causing the access
control server to initiate SCA for the other transaction.
4. The authentication platform of claim 1, the processor is further
configured to: display a graphical user interface (GUI) dashboard
for use by the regulatory entity to evaluate fraud in payment
transactions within the market; display, via the GUI, first
historical data indicating a level of fraud present in transactions
not mandated to be authenticated with SCA based on satisfying the
risk threshold and the transaction limit set by the regulatory
entity; and display, via the GUI, second historical data indicating
a level of fraud present in transactions mandated to be
authenticated with SCA based on not satisfying one or more of the
risk threshold and the transaction limit set by the regulatory
entity.
5. The authentication platform of claim 4, wherein one or more of
the first historical data and the second historical data include an
approval rate and basis points of fraud.
6. The authentication platform of claim 1, wherein the RBA result
data further include at least one reason code that indicates at
least one factor that influenced the generated risk score.
7. The authentication platform of claim 1, the processor is further
configured to: display a graphical user interface (GUI) dashboard
for use by the regulatory entity to alter configuration of the
authentication platform for transactions occurring in the market,
the GUI dashboard allowing a regulator to alter one or more of the
risk threshold and the transaction limit; and reconfigure one or
more of the risk threshold and the transaction limit based on input
received from the regulator via the GUI.
8. A computer-implemented method for authenticating an online user
in a transaction without use of strong consumer authentication
(SCA), the method implemented on a computing device comprising a
memory device coupled to at least one processor, and the method
comprises: receiving an authentication request message for a
transaction involving a market regulated by a regulatory entity,
the authentication request message includes authentication data and
a transaction value; extracting the authentication data from the
authentication request message; generating, based at least in part
on the extracted authentication data, risk-based authentication
(RBA) result data that includes a risk score for the transaction;
determining that a risk of fraud in the transaction satisfies a
risk threshold established by the regulatory entity by evaluating
the risk score relative to the risk threshold; determining that the
transaction value is below a transaction limit set by the
regulatory entity, the transaction limit identifies a threshold
transaction value below which strong consumer authentication may be
avoided for transactions satisfying the risk threshold; and
transmitting an authentication response message authenticating the
transaction without strong consumer authentication having been
performed on the transaction based on the determined risk of fraud
satisfying the risk threshold and further based on the determined
transaction amount being below the transaction limit.
9. The method of claim 8, further comprising: generating an
enhanced authentication request message associated with the
transaction, the enhanced authentication request message including
data indicating that the transaction is not mandated for strong
consumer authentication; and transmitting the enhanced
authentication request message to an access control server
(ACS).
10. The method of claim 9, further comprising: generating another
enhanced authentication request message associated with another
transaction, the other enhanced authentication request message
including data indicating that the transaction is mandated for
strong consumer authentication; and transmitting the other enhanced
authentication request message to an access control server, the
indicated mandate causing the access control server to initiate SCA
for the other transaction.
11. The method of claim 8, the processor is further configured to:
displaying a graphical user interface (GUI) dashboard for use by
the regulatory entity to evaluate fraud in payment transactions
within the market; displaying, via the GUI, first historical data
indicating a level of fraud present in transactions not mandated to
be authenticated with SCA based on satisfying the risk threshold
and the transaction limit set by the regulatory entity; and
displaying, via the GUI, second historical data indicating a level
of fraud present in transactions mandated to be authenticated with
SCA based on not satisfying one or more of the risk threshold and
the transaction limit set by the regulatory entity.
12. The method of claim 11, wherein one or more of the first
historical data and the second historical data include an approval
rate and basis points of fraud.
13. The method of claim 8, wherein the RBA result data further
include at least one reason code that indicates at least one factor
that influenced the generated risk score.
14. The method of claim 8, further comprising: displaying a
graphical user interface (GUI) dashboard for use by the regulatory
entity to alter configuration of the computing device for
transactions occurring in the market, the GUI dashboard allowing a
regulator to alter one or more of the risk threshold and the
transaction limit; and reconfiguring one or more of the risk
threshold and the transaction limit based on input received from
the regulator via the GUI.
15. At least one non-transitory computer-readable storage media
having computer-executable instructions embodied thereon for
authenticating an online user in a transaction without use of
strong consumer authentication (SCA), wherein when executed by at
least one processor, the computer-executable instructions cause the
at least one processor to: receive an authentication request
message for a transaction involving a market regulated by a
regulatory entity, the authentication request message includes
authentication data and a transaction value; extract the
authentication data from the authentication request message;
generate, based at least in part on the extracted authentication
data, risk-based authentication (RBA) result data that includes a
risk score for the transaction; determine that a risk of fraud in
the transaction satisfies a risk threshold established by the
regulatory entity by evaluating the risk score relative to the risk
threshold; determine that the transaction value is below a
transaction limit set by the regulatory entity, the transaction
limit identifies a threshold transaction value below which strong
consumer authentication may be avoided for transactions satisfying
the risk threshold; and transmit an authentication response message
authenticating the transaction without strong consumer
authentication having been performed on the transaction based on
the determined risk of fraud satisfying the risk threshold and
further based on the determined transaction amount being below the
transaction limit.
16. The non-transitory computer-readable storage media of claim 15,
the computer-executable instructions further cause the at least one
processor to: generate an enhanced authentication request message
associated with the transaction, the enhanced authentication
request message including data indicating that the transaction is
not mandated for strong consumer authentication; and transmit the
enhanced authentication request message to an access control server
(ACS).
17. The non-transitory computer-readable storage media of claim 16,
the computer-executable instructions further cause the at least one
processor to: generate another enhanced authentication request
message associated with another transaction, the other enhanced
authentication request message including data indicating that the
transaction is mandated for strong consumer authentication; and
transmit the other enhanced authentication request message to an
access control server, the indicated mandate causing the access
control server to initiate SCA for the other transaction.
18. The non-transitory computer-readable storage media of claim 15,
the computer-executable instructions further cause the at least one
processor to: display a graphical user interface (GUI) dashboard
for use by the regulatory entity to evaluate fraud in payment
transactions within the market; display, via the GUI, first
historical data indicating a level of fraud present in transactions
not mandated to be authenticated with SCA based on satisfying the
risk threshold and the transaction limit set by the regulatory
entity; and displaying, via the GUI, second historical data
indicating a level of fraud present in transactions mandated to be
authenticated with SCA based on not satisfying one or more of the
risk threshold and the transaction limit set by the regulatory
entity.
19. The non-transitory computer-readable storage media of claim 18,
wherein one or more of the first historical data and the second
historical data include an approval rate and basis points of
fraud.
20. The non-transitory computer-readable storage media of claim 15,
the computer-executable instructions further cause the at least one
processor to: displaying a graphical user interface (GUI) dashboard
for use by the regulatory entity to alter configuration of the
computing device for transactions occurring in the market, the GUI
dashboard allowing a regulator to alter one or more of the risk
threshold and the transaction limit; and reconfiguring one or more
of the risk threshold and the transaction limit based on input
received from the regulator via the GUI.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] This application claims priority to U.S. Provisional Patent
Application No. 62/688,528, filed Jun. 22, 2018, entitled "SYSTEMS
AND METHODS FOR AUTHENTICATING ONLINE USERS," U.S. Provisional
Patent Application No. 62/688,529, filed Jun. 22, 2018, entitled
"SYSTEMS AND METHODS FOR AUTHENTICATING ONLINE USERS WITH AN ACCESS
CONTROL SERVER," U.S. Provisional Patent Application No.
62/688,546, filed Jun. 22, 2018, entitled "SYSTEMS AND METHODS FOR
AUTHENTICATING ONLINE USERS IN REGULATED ENVIRONMENTS," and U.S.
Provisional Patent Application No. 62/688,532, filed Jun. 22, 2018,
entitled "SYSTEMS AND METHODS FOR AUTHENTICATING ONLINE USERS," the
entire contents and disclosures of which are hereby incorporated by
reference herein in their entirety.
BACKGROUND
[0002] The present application relates generally to authenticating
online users over an electronic network, and more particularly, to
authenticating online users using risk-based authentication in
regulated environments.
[0003] Transactions conducted over electronic payment networks are
growing exponentially. For card-not-present transactions (e.g.,
transactions in which the consumer does not actually provide a
payment card to the merchant), fraud is markedly higher.
Accordingly, for such transactions, authentication procedures are
often implemented to verify that the alleged cardholder is, in
fact, the actual or legitimate cardholder.
[0004] In at least some known authentication systems, the bank that
issued the payment card for the transaction (referred to as the
issuer) contracts with an access control server (ACS) for
authentication services. Specifically, the ACS analyzes at least
some of the data associated with the transaction, determines
whether or not it is likely that the alleged cardholder is, in
fact, the actual or legitimate cardholder, and reports that
determination to the issuer.
[0005] Some authentication systems may also implement strong
consumer authentication (SCA) (or just "strong authentication") for
certain transactions. For example, an issuing bank may insist on
authenticating consumers during online transactions (e.g., with a
username and password, or by SMS text message). Such tools may help
issuers verify identity and authenticate cardholders, but they may
also increase friction with the cardholders, which sometimes leads
to transactions being abandoned. This can result in losses to the
merchant and to the underlying payment card network. Further, some
SCA methods such as passwords may be less trustworthy than others,
which may lead to increased risk in transactions.
[0006] In some markets, regulators may require SCA on digital
transactions. For example, the Reserve Bank of India (RBI), India's
central bank, requires that all digital transactions are
authenticated using SCA. While these regulations have reduced fraud
in India, they create considerable friction during the check-out
experience. Cardholders get frustrated with having to provide a
password or being timed out of the transaction, and merchants are
dissatisfied when cardholders abandon transactions due to their
frustrations.
[0007] Accordingly, it is desirable to have a computer-implemented
authentication platform that is capable of providing a network in
which some transactions can be authenticated without SCA.
BRIEF DESCRIPTION
[0008] In one aspect, an authentication platform for authenticating
an online user in a transaction without use of strong consumer
authentication (SCA) is provided. The authentication platform
includes a memory device and at least one processor coupled to the
memory device. The authentication platform receives an
authentication request message for a transaction involving a market
regulated by a regulatory entity. The authentication request
message includes authentication data and a transaction value. The
authentication platform also extracts the authentication data from
the authentication request message. The authentication platform
further generates, based at least in part on the extracted
authentication data, risk-based authentication (RBA) result data
that includes a risk score for the transaction. The authentication
platform also determines that a risk of fraud in the transaction
satisfies a risk threshold established by the regulatory entity by
evaluating the risk score relative to the risk threshold. The
authentication platform further determines that the transaction
value is below a transaction limit set by the regulatory entity.
The transaction limit identifies a threshold transaction value
below which strong consumer authentication may be avoided for
transactions satisfying the risk threshold. The authentication
platform also transmits an authentication response message
authenticating the transaction without strong consumer
authentication having been performed on the transaction based on
the determined risk of fraud satisfying the risk threshold and
further based on the determined transaction amount being below the
transaction limit.
[0009] In another aspect, a computer-implemented method for
authenticating an online user in a transaction without use of
strong consumer authentication (SCA) is provided. The method is
implemented on a computing device comprising a memory device
coupled to at least one processor. The method includes receiving an
authentication request message for a transaction involving a market
regulated by a regulatory entity. The authentication request
message includes authentication data and a transaction value. The
method also includes extracting the authentication data from the
authentication request message. The method further includes
generating, based at least in part on the extracted authentication
data, risk-based authentication (RBA) result data that includes a
risk score for the transaction. The method also includes
determining that a risk of fraud in the transaction satisfies a
risk threshold established by the regulatory entity by evaluating
the risk score relative to the risk threshold. The method further
includes determining that the transaction value is below a
transaction limit set by the regulatory entity. The transaction
limit identifies a threshold transaction value below which strong
consumer authentication may be avoided for transactions satisfying
the risk threshold. The method also includes transmitting an
authentication response message authenticating the transaction
without strong consumer authentication having been performed on the
transaction based on the determined risk of fraud satisfying the
risk threshold and further based on the determined transaction
amount being below the transaction limit.
[0010] In a further aspect, at least one non-transitory
computer-readable storage media having computer-executable
instructions embodied thereon for authenticating an online user in
a transaction without use of strong consumer authentication (SCA)
is provided. When executed by at least one processor, the
computer-executable instructions cause the at least one processor
to receive an authentication request message for a transaction
involving a market regulated by a regulatory entity. The
authentication request message includes authentication data and a
transaction value. The computer-executable instructions also cause
the processor to extract the authentication data from the
authentication request message. The computer-executable
instructions also cause the processor to generate, based at least
in part on the extracted authentication data, risk-based
authentication (RBA) result data that includes a risk score for the
transaction. The computer-executable instructions also cause the
processor to determine that a risk of fraud in the transaction
satisfies a risk threshold established by the regulatory entity by
evaluating the risk score relative to the risk threshold. The
computer-executable instructions also cause the processor to
determine that the transaction value is below a transaction limit
set by the regulatory entity. The transaction limit identifies a
threshold transaction value below which strong consumer
authentication may be avoided for transactions satisfying the risk
threshold. The computer-executable instructions also cause the
processor to transmit an authentication response message
authenticating the transaction without strong consumer
authentication having been performed on the transaction based on
the determined risk of fraud satisfying the risk threshold and
further based on the determined transaction amount being below the
transaction limit.
BRIEF DESCRIPTION OF THE DRAWINGS
[0011] FIGS. 1-12 show example embodiments of the methods and
systems described herein.
[0012] FIG. 1 is a schematic diagram illustrating an example RBA
platform in communication with a multi-party payment card system
for processing payment transactions in accordance with one
embodiment of the present disclosure.
[0013] FIG. 2 is an expanded block diagram of an example embodiment
of a computer system used in processing payment transactions that
includes a server system in accordance with one example embodiment
of the present disclosure.
[0014] FIG. 3 illustrates an example configuration of a server
system such as the server system shown in FIG. 2.
[0015] FIG. 4 illustrates an example configuration of a client
system shown in FIG. 2.
[0016] FIG. 5 is a schematic diagram illustrating transaction flow
in an example authentication system.
[0017] FIG. 6 is a schematic diagram illustrating transaction flow
in another example authentication system.
[0018] FIG. 7 is a flow diagram of an example method for
authenticating a user on behalf of an access control server
(ACS).
[0019] FIG. 8 is a data flow diagram of another example method for
authenticating an online user.
[0020] FIG. 9 is a flow diagram of another example method for
authenticating an online user.
[0021] FIG. 10 is a flow diagram of a further example method for
authenticating an online user on behalf of an ACS.
[0022] FIGS. 11A and 11B are swim-lane diagrams illustrating
additional example embodiments involving conditional SCA evaluation
on transactions associated with a regulated market.
[0023] FIG. 12 is a flow diagram of a further example advanced
authentication process for authenticating an online user and for
increasing approvals, reducing fraud, and improving consumer
experience.
[0024] Although specific features of various embodiments may be
shown in some drawings and not in others, this is for convenience
only. Any feature of any drawing may be referenced and/or claimed
in combination with any feature of any other drawing.
DETAILED DESCRIPTION
[0025] The systems and methods described herein are directed to
"conditional" strong consumer authentication of online users in
regulated markets. A risk-based authentication enabled
(RBA-enabled) directory server stores an authentication profile
which includes rules for performing and routing authentication
requests. The RBA-enabled directory server receives an
authentication request message for a transaction involving a market
regulated by a regulatory entity. The authentication request
message includes authentication data and a transaction value. The
RBA-enabled directory server extracts the authentication data from
the authentication request message. The RBA-enabled directory
server generates risk-based authentication result data based on the
extracted authentication data, including a risk score for the
transaction. Further, the RBA-enabled directory server determines
that a risk of fraud in the transaction is below a regulated risk
threshold established by the regulatory entity by comparing the
risk score to the regulated risk threshold. The RBA-enabled
directory server also determines that the transaction value is
below a transaction limit set by the regulatory entity. The
transaction limit identifies a threshold transaction below which
strong consumer authentication may be avoided for transactions
below the regulated risk threshold. The RBA-enabled directory
server transmits an authentication response message authenticating
the transaction based on the determined risk of fraud being below
the regulated risk threshold and further based on the determined
transaction value being below the transaction limit without strong
consumer authentication having been performed on the
transaction.
[0026] As noted above, in at least some known authentication
systems, a bank that issued a payment card for a transaction
(referred to as the issuer) contracts with an ACS for
authentication services. Specifically, the ACS analyzes at least
some of the data associated with the transaction, determines
whether or not it is likely that the alleged cardholder is, in
fact, the actual or legitimate cardholder, and reports that
determination to the issuer. In some markets, regulators may
mandate strong consumer authentication on certain types of
transactions, such as card-not-present (CNP) transactions. Such
regulation is directed at reducing online fraud, but often at the
expense of customer and merchant satisfaction. For example, forcing
customers to provide password or pin information or respond to a
text message for 100% of transactions within that market increases
friction in online purchasing environments, leading to increased
rates of abandonment due to the customers' frustrations.
[0027] Accordingly, to address these limitations of known
authentication systems, the systems and methods described herein
allow a more discretionary approach to the use of SCA in regulated
markets. In example embodiments described herein, the RBA-enabled
directory server allows low-risk, low-value transactions to avoid
SCA step-up challenges to the consumer, while forcing SCA for
transactions above a particular transaction value (e.g., above
2,000 rupees), or for transactions that are above a particular risk
threshold (e.g., "medium" or "high" risk transactions).
[0028] More specifically, in an example embodiment, the RBA-enabled
directory server allows regulators to set both a transaction value
threshold and a risk threshold for when SCA may be avoided. Some
regulators may agree that, for certain low-risk, low-value
transactions, the increased friction that SCA adds to the
transaction process may not be worth the marginal reduction in
fraud in those situations. For example, the occurrence of fraud in
low-value transactions may be relatively small and, with the value
of those transactions being low, the amount of loss due to
low-value transactions may also be relatively small. Further, if
transactions can be evaluated for risk by a risk-based decision
engine, those transactions with a low level of risk may represent
only a small fraction of fraud, thereby further marginalizing their
contribution to overall fraud. As such, regulators may configure
the RBA-enabled directory server to avoid SCA when the transaction
value is low and when the risk that the transaction is fraudulent
is determined to be low.
[0029] In some embodiments, the RBA-enabled directory server
provides a graphical user interface (GUI) to the regulators that
provides an insight into fraud within their regulated market, and
may allow the regulators to directly configure operational aspects
of the RBA-enabled directory server, such as changing threshold
values used in the conditional SCA process for their market. The
GUI may allow the regulators to evaluate current performance of
existing thresholds, displaying and comparing fraud data on
transactions above or below the configured thresholds, such as the
basis points of fraud lost during a particular period of time. The
GUI may also allow regulators to evaluate potential threshold
values, providing an estimate of fraud levels based on a set of
prospective threshold values. As such, regulators may use such
simulations to determine how they may set or change threshold
values for their market.
[0030] As described herein, RBA refers to performing authentication
on transactions using a rich, comprehensive data set that is
generally not available to an issuer or ACS. For example, as
described herein, RBA may include performing authentication using
the 3DS 2 Protocol (for example versions 2.0, 2.1, 2.2, and
subsequent versions of the 3DS Protocol). The 3DS Protocols are
owned and updated by EMVCo. Further, as described herein, RBA may
be performed by an authentication platform that is operated by a
payment processing network. Thus, for authentication purposes, the
authentication platform is capable of leveraging large volumes of
historical transaction data for all transactions previously
processed by the payment processing network (as compared to the
relatively small number of transactions processed by a particular
ACS).
[0031] Specifically, in the systems and methods described herein,
the authentication system uses the 3DS 2 Protocol (or subsequent
versions of the 3DS Protocol) for authentication, and performs RBA
on transactions to determine when the transaction may avoid SCA and
when SCA is mandated based on the regulator-configured threshold
value and risk value. An RBA-enabled directory server is
communicatively coupled to a RBA engine (which may be collectively
referred to as an authentication platform). The RBA-enabled
directory server and the RBA engine facilitate evaluating
transactions to determine when SCA is mandated, as described
herein. The RBA-enabled directory server and the RBA engine may be
operated, for example, by an interchange network (e.g., a payment
processing network).
[0032] The RBA-enabled directory server receives an authentication
request (AReq) message from a 3DS server. The RBA-enabled directory
server may evaluate the transaction to determine with which
market(s) the transaction is associated (e.g., based on merchant,
merchant bank, issuing bank, consumer, and so forth). If the
transaction is associated with a regulated market that is
configured for "conditional SCA" as described herein, then the
RBA-enabled directory server compares the transaction value with
the configured transaction value threshold set by the regulators of
the associated market. If the transaction value is below the
transaction value threshold, then the RBA engine evaluates the risk
of the transaction using transaction data and other data available
to the RBA-enabled directory server.
[0033] In the example embodiment, the RBA result data generated by
the RBA engine includes a risk score, a risk analysis, and at least
one reason code. The risk score is a score representing a
determined riskiness of the transaction, with lower scores
indicating lower risk and higher scores indicating higher risk. In
other words, the risk score represents a likelihood that the
suspect cardholder (e.g., the person attempting to perform a
transaction) is the legitimate cardholder having the privileges to
use the payment card to perform a payment transaction. For example,
the risk score may be represented by a number from 0-999 and/or by
a risk threshold category from 0-19. Those of skill in the art will
appreciate that any suitable risk score may be used.
[0034] The risk analysis is a description of a level of risk
corresponding to the risk score (e.g., low risk, medium risk, or
high risk). Further the reason codes include one or more factors
that influenced the risk score. In some embodiments, the reason
codes are generated using reason code categories and anchors, as
described herein. In some embodiments, the reason codes are
affected by rules and/or a combination of the rules and the model.
The RBA engine transmits the RBA result data to the RBA-enabled
directory server.
[0035] In some scenarios, the RBA-enabled directory server embeds
the RBA result data into the AReq message to generate an enhanced
or enriched AReq message to be sent to the ACS for the transaction.
For example, in some embodiments, the RBA result data is appended
to the AReq message as an extensible markup language (XML)
extension of the AReq message. For example, the extension may have
the following format:
TABLE-US-00001 "name": "ACS RBA", "id": "A000000004-acsRBA", "
criticalityIndicator": "true", "data": { "status":"success",
"score":"150", "decision":"low risk", "reasonCode1":"Y",
"reasonCode2":"J"}
where "score" is the risk score, "decision" is the risk analysis,
and "reasonCode1" and "reasonCode2" are the reason codes. In the
exemplary embodiment, the reason codes are transmitted as a single
letter each. In other embodiments, the reason codes may be
represented in different methods. In some embodiments, reasonCode2
is transmitted by the merchant to provide the merchant's assessment
of the transaction. Alternatively, the RBA result data may be
embedded into the AReq message to generate an enhanced or enriched
AReq message using any suitable process.
[0036] The enhanced AReq message may then be transmitted from the
RBA-enabled directory server to the ACS. The ACS then analyzes the
RBA result data in the enhanced AReq message to make an
authentication decision. That is, in the example embodiment, the
ACS may determine to fully authenticate the transaction, deny
authentication for the transaction, or perform additional
authentication (e.g., by issuing a step-up challenge to the
cardholder) for the transaction, based on at least one of a risk
score, the risk analysis, and the reason codes. Accordingly, the
ACS may not perform the RBA analysis, but is still able to leverage
the results of that analysis to make an authentication decision
(e.g., by using the results in their own fraud analysis platform),
generally resulting in more approvals with less fraud. Thus, the
RBA-enabled directory server and the RBA engine may perform the RBA
analysis on behalf of the ACS. In some embodiments, the ACS
receives authentication data from a plurality of sources. Further,
the RBA-enabled directory server determines whether the transaction
requires SCA as mandated by regulators of an associated market.
[0037] In the example embodiment, the authentication platform
compares the RBA result data to a stored authentication profile.
The authentication profile contains a plurality of rules for the
processing of authentication requests. In some embodiments, the
authentication profile is provided by an issuer computing device
associated with an issuer bank. Examples of the rules include, but
are not limited to, how to proceed when the ACS is unavailable,
information to include in the RBA, issuer-provided risk level
thresholds for the risk score and risk levels, decision making risk
thresholds, and specialized rules (such as all cross-border
transactions are to be submitted to the ACS). In some embodiments,
the authentication profile may include regulator-imposed threshold
values for risk categories or transaction threshold values for
particular markets that define when SCA is mandated. The
authentication profile is stored at the RBA platform, and can be
accessed whenever a risk score is determined.
[0038] In the example embodiment, the authentication platform also
compares the RBA result data to the authentication profile to
determine the risk level associated with the transaction associated
with the authentication request. In some embodiments, the
authentication platform compares the risk score to one or more
thresholds in the authentication profile to determine the risk
level associated with the transaction. In other embodiments, the
authentication platform compares the risk analysis, the reason
codes, and/or any other combination of data from the RBA result
data and potentially some or all of the authentication data to the
authentication profile to determine the risk level associated with
this transaction. For example, a risk score of 900 or less may be
considered low risk, a risk score between 900 and 980 may be
considered medium risk, and a risk score above 980 may be
considered high risk. Those skilled in the art will appreciate that
any suitable risk score thresholds and any number of risk levels
may be used.
[0039] In the example embodiment, the authentication platform
determines if the risk level is high risk. In the example
embodiment, in the case of a high risk transaction, the
authentication platform may deny the transaction. The
authentication platform may transmit an authentication response
(ARes) message including the denial to the 3DS server. The 3DS
server may transmit the ARes message including the denial to the
merchant, where the merchant determines whether or not to proceed
with the authorization process. In these embodiments, where the
merchant begins the authorization process after having received a
denial, the transaction is considered to be merchant only
authentication, where the merchant assumes the risk for the
transaction.
[0040] The authentication platform determines if the transaction is
medium risk or low risk. If the transaction is low risk, the
authentication platform may approve the transaction and transmit an
authentication response (ARes) message including the approval to
the 3DS server, where at least one of the 3DS server and the
merchant may initiate the authorization process. In some
embodiments, if the transaction is subject to a regulated market,
the transaction may be authorized without SCA if the transaction is
below the transaction value threshold for that market, or the
transaction may be mandated to be subject to SCA if the transaction
value is above the threshold for that market. If the transaction is
medium risk, the authentication platform may issue a step-up
challenge to the cardholder. If the transaction is subject to a
regulated market, SCA may be mandated in that market. Based on the
results of the step-up challenge, the authentication platform may
approve or deny the transaction. In some embodiments, if the
transaction is medium risk, the authentication platform transmits
the RBA result data to the ACS, so that the ACS will perform the
step-up challenge. In other embodiments, the authentication
platform may take different steps at different risk levels and have
additional or fewer risk levels to analyze based on the
authentication profile.
[0041] The 3DS 2 Protocol (and subsequent versions of the 3DS
Protocol) provides a number of benefits to cardholders, issuers,
and merchants. It reduces risk of unauthorized transactions through
an approach that incorporates a rich, comprehensive set of data to
make authentication decisions. For cardholders, it provides a
simple, secure, and familiar online authentication experience,
regardless of payment channel or device. For issuers, it allows for
"frictionless" authentication, in which an explicit cardholder
step-up authentication is not required or performed. This enables
more intelligent risk assessment decisions and the ability to
selectively challenge the cardholder as needed. This also improves
cardholder experience and overall cardholder loyalty to issuers.
For merchants, the 3DS 2 Protocol decreases fraud on all
authenticated transactions, and increases revenue potential from
reduced friction and reduced cart abandonment (i.e., cardholders
deciding not to complete a transaction after they have already
selected one or more items to be purchased), especially for mobile
payment channels. This also improves cardholder experience and
overall cardholder loyalty to merchants. The 3DS 2 Protocol and RBA
may support additional payment channels, such as, but not limited
to, card-on-file, wallet, mobile, in-app, and Internet of Things
(IoT).
[0042] Using 3DS 2 Protocol (or subsequent versions of the 3DS
Protocol), payment networks see 100% of all authentication requests
globally on all cards on their brands. No other party, including
issuers and ACS providers, is able to provide this global
visibility. This global visibility may be leveraged to provide a
consistent, standards-based risk analysis of transactions on behalf
of issuers, enabling a market-wide risk-based authentication
approach.
[0043] As compared to previous authentication methods (e.g., 3DS
1.0), the 3DS 2 Protocol (and subsequent versions of the 3DS
Protocol) allows for approximately ten times the amount of
transaction data to be gathered, analyzed, and utilized to prevent
fraud. The additional data included in the 3DS Protocol increases
data exchange between merchants and issuers, and improves
risk-based authentication (RBA) decisioning. RBA allows issuers to
examine every authentication request through transaction risk
analysis, while focusing fraud prevention efforts on transactions
that prevent the most risk. Further, RBA utilizes both behavioral
and transactional inputs in conjunction with a risk engine to
determine riskiness of a transaction. The RBA method of cardholder
authentication dynamically calculates a risk assessment for any
given e-commerce transaction in real time. The assessment can then
be used to authenticate the cardholder in a frictionless
manner.
[0044] The RBA methodology includes three components that work
together to provide authentication of cardholders. First, the
underlying data model is used to provide a basis for the
authentication. The underlying data model may include 3DS data,
which may include cardholder data, behavioral data, location data,
merchant data, and device data. The underlying data model may also
include interchange network data, such as, but not limited to, past
risk scores, authentication approvals, authorization history,
chargeback data, and fraud data.
[0045] The RBA methodology may use in the underlying data model in
one or more measurement methodologies. The measurement
methodologies may include short term velocities and ratios,
including measuring behavior consistency and changes, such as
frequency, amount spent, time, location, and device. The
measurement methodologies may also include long term velocities and
ratios, which include measurement of behavior and anomaly
detection. The measurement methodologies may further include
continuous measurement across the payment network.
[0046] The RBA methodology may then use the underlying data model
and the measurement methodology in a rules engine. The rules engine
may include thresholds for interpreting measurement results, rules
for combining results of measurements, and rules for combining
other data with models and measurements.
[0047] Transactions deemed safe or low risk are silently
authenticated (i.e., so-called "frictionless" authentication),
while higher risk transactions are subjected to step-up
authentication. When a low risk transaction is silently
authenticated, so much data has already been gathered that further
authentication adds little to no value. Accordingly, RBA
effectively replaces the need for an explicit interaction with the
cardholder for every transaction, but transactions are still fully
authenticated, with liability resting with the issuer. Thus, more
transactions are completed with minimal cardholder disruption,
aiding e-commerce growth.
[0048] An example of a safe (or low-risk) transaction may include,
where the cardholder has a positive transaction history, is
performing the transaction with a known device with a positive
association with the cardholder, the cardholder is in a typical
geolocation, the device is using a typical IP address, the
transaction fits within a typical behavioral and transaction
pattern, and the shipping address has been used with the payment
account number (PAN) and is the same as the last transaction. The
cardholder buys a present to be delivered to his house. An example
of a medium risk transaction may include, where the cardholder has
a positive transaction history, is using an unknown device with no
known association with the cardholder, the device is at a
non-typical geolocation and IP address, but is typical behavioral,
cardholder, and transaction pattern. For example, the cardholder is
on travel and purchases Internet Access at a hotel. An example of a
high risk transaction may include, where there are anomalous
velocities detected with the cardholder in network, is using an
unknown device with no known association with the cardholder, the
device is at a non-typical geolocation and IP address, and there is
anomalous behavior patterns detected. The cardholder purchases over
$600 of clothing in Texas right after the cardholder purchased
lunch in St. Louis.
[0049] One goal of RBA is to minimize the number of transactions
that require active (i.e., step-up) authentication, while keeping
fraud to a minimum and improving consumer friction points during
the transaction process. The goal of RBA is to silently eliminate
unnecessary friction on low risk transactions. Approximately 90% of
transactions are deemed low risk and would then be authenticated
without any action and would proceed to the Authorization process.
This greatly decreases the amount of processing and message traffic
necessary to authenticate transactions. 5-8% of transactions would
be considered medium risk and the cardholder would be asked to
authenticate themselves, such as through a step-up challenge. Then
1-2% of transactions would be deemed high risk and would fail
authentication. With RBA, the information gathered enables
transaction scoring and classification into low, medium, and high
risk, allowing the issuer and ACS to take appropriate action.
[0050] The 3DS 2 Protocol (and subsequent versions of the 3DS
Protocol) enables a market-wide level risk analysis of all
transactions that reach directory server 510. Each transaction can
be scored and/or flagged based on the global data available using
the 3DS 2 Protocol (and subsequent versions of the 3DS Protocol).
Additionally, the payment processor operating the directory server
510 has the ability to see cardholder activity across the digital
and physical domains, and can utilize this expanded view to improve
scoring. In contrast, traditional authentication service providers
may only address the digital domain. For example, a payment
processor could indicate if a particular device is associated with
fraud, and flag that device for issuers in future transactions. The
issuer may then reject transactions involving that device or prompt
for additional authentication (e.g., through two-factor
authentication).
[0051] The following Table 1 lists a number of the data elements
that are used in the 3DS 2 Protocol for authentication. For
example, at least some of these data elements may be included in
the authentication data included in the AReq sent to directory
server 510. The eighteen data elements that are also part of the
3DS 1.0 Protocol are bolded in Table 1. Those of skill in the art
will appreciate that the number of rich data elements could grow
beyond those listed below (e.g., in future versions of the 3DS
Protocol), and could include over one hundred and seventy data
elements. Further, an app-based transaction (e.g., carried out
using a mobile computing device) could provide even more data
elements than browser-based transactions. In addition, a
transaction performed using an Android device could have over one
hundred and thirty additional elements. The authentication data may
also be divided by category, such as: transaction data (amount,
currency, date, and time), device data (IP address, device info,
and channel data), cardholder data (account number and shipping
address), and merchant data (name, category, and country).
TABLE-US-00002 TABLE 1 Data Element 1 3DS Requestor Authentication
Information 2 3DS Requestor Challenge Indicator 3 3DS Requestor ID
4 3DS Requestor Initiated Indicator 5 3DS Requestor Name 6 3DS
Requestor Non-Payment Authentication Indicator 7 3DS Requestor
Prior Transaction Authentication Information 8 3DS Requestor URL 9
3DS Server Operator ID 10 3DS Server Reference Number 11 3DS Server
Transaction ID 12 3DS Server URL 13 Account Type 14 Acquirer BIN 15
Acquirer Merchant ID 16 ACS Challenge Mandated Indicator 17 ACS
Counter ACS to SDK 18 ACS HTML 19 ACS Operator ID 20 ACS Reference
Number 21 ACS Rendering Type 22 ACS Signed Content 23 ACS
Transaction ID 24 ACS UI Type 25 Address Match Indicator 26
Authentication Method 27 Authentication Type 28 Authentication
Value 29 Browser Accept Headers 30 Browser IP Address 31 Browser
Java Enabled 32 Browser Language 33 Browser Screen Color Depth 34
Browser Screen Height 35 Browser Screen Width 36 Browser Time Zone
37 Browser User-Agent 38 Card/Token Expiry Date 39 Cardholder
Account Identifier 40 Cardholder Account Information 41 Cardholder
Account Number 42 Cardholder Billing Address City 43 Cardholder
Billing Address Country 44 Cardholder Billing Address Line 1 45
Cardholder Billing Address Line 2 46 Cardholder Billing Address
Line 3 47 Cardholder Billing Address Postal Code 48 Cardholder
Billing Address State 49 Cardholder Email Address 50 Cardholder
Home Phone Number 51 Cardholder Mobile Phone Number 52 Cardholder
Name 53 Cardholder Shipping Address City 54 Cardholder Shipping
Address Country 55 Cardholder Shipping Address Line 1 56 Cardholder
Shipping Address Line 2 57 Cardholder Shipping Address Line 3 58
Cardholder Shipping Address Postal Code 59 Cardholder Shipping
Address State 60 Cardholder Work Phone Number 61 Challenge
Additional Information Text 62 Challenge Cancelation Indicator 63
Challenge Data Entry 64 Challenge HTML Data Entry 65 Challenge
Information Header 66 Challenge Information Label 67 Challenge
Information Text 68 Challenge Information Text Indicator 69
Challenge Selection Information 70 Challenge Window Size 71 Device
Channel 72 Device Information 73 Device Rendering Options Supported
74 DS Reference Number 75 DS Transaction ID 76 DS URL 77 Electronic
Commerce Indicator 78 EMV Payment Token Indicator 79 Expandable
Information Label 1 80 Expandable Information Text 1 81 Instalment
Payment Data 82 Interaction Counter 83 Issuer Image 84 Merchant
Category Code 85 Merchant Country Code 86 Merchant Name 87 Merchant
Risk Indicator 88 Message Category 89 Message Extension 90 Message
Type 91 Message Version Number 92 Notification URL 93 OOB App Label
94 OOB App URL 95 OOB Continuation Indicator 96 OOB Continuation
Label 97 Payment System Image 98 Purchase Amount 99 Purchase
Currency 100 Purchase Currency Exponent 101 Purchase Date &
Time 102 Recurring Expiry 103 Recurring Frequency 104 Resend
Challenge Information Code 105 Resend Information Label 106 Results
Message Status 107 SDK App ID 108 SDK Counter SDK to ACS 109 SDK
Encrypted Data 110 SDK Ephemeral Public Key (Qc) 111 SDK Reference
Number 112 SDK Transaction ID 113 Submit Authentication Label 114
Transaction Status 115 Transaction Status Reason 116 Transaction
Type 117 Why Information Label 118 Why Information Text
[0052] In the example embodiment, transactions are categorized
"merchant only" or "fully authenticated." "Fully authenticated"
transactions are generally considered to be low risk transactions
that have been authenticated. "Merchant only" transactions are more
risky transactions. In some embodiments, "merchant only"
transactions have been authenticated. In the example embodiment,
one or more indicators in the authentication response indicate
whether a transaction is "merchant only" or "fully authenticated."
One or more indicators may also indicate whether or not
authentication was attempted on the transaction. This information
is used by the merchant to determine whether or not to begin the
authorization process for the transaction. In some embodiments,
this information is also stored in a database and is referred to by
at least one of the interchange network and the issuer processor
during the authorization process.
[0053] In some further embodiments, the authentication platform
determines whether the authentication request message complies with
the 3DS 2 Protocol or subsequent versions of the 3DS Protocol. If
the authentication request message does not comply with the
appropriate 3DS Protocols, the authentication platform bypasses
determining if the ACS is available. In this situation, the
authentication platform transmits an authentication response
message indicating that the transaction is considered merchant only
and that no authentication was attempted.
[0054] In some embodiments, the authentication platform determines
a risk level based on the RBA result data. If the risk level is
low, the authentication platform embeds an indicator in the
authentication response message indicating that the transaction is
"fully authenticated." If the risk level is not low, the
authentication platform embeds one or more indicators in the
authentication response message indicating that the transaction is
a merchant only transaction and that authentication was
attempted.
[0055] In the example embodiment, the authentication platform
performs the authentication process on the transaction, including
RBA. This analysis is based on a machine learning model where, over
time, the authentication platform is capable of improving its
ability to determine the risk level associated with transactions.
The authentication platform analyzes transactions that are
authenticated by the ACS and compares these transactions with
historical data to generate a risk model for each issuer. By
comparing the data points in each transaction, the risk model will
indicate the amount of risk associated with each transaction based
on the authentication data in the corresponding authentication
requests. This allows the authentication platform to analyze
transactions when the ACS is unavailable and perform authentication
on these transactions to provide a response to the authentication
request. Accordingly, the authentication platform may determine
that a received authorization request is substantially similar to a
previous transaction that the ACS scored at low risk. Thus allowing
the authentication platform to determine that the received
transaction is low risk with a degree of certainty.
[0056] At least one of the technical problems addressed by this
system includes: (i) high network load based at least in part on
step-up challenging most or all card-not-present transactions which
results in network delays and reduced bandwidth; (ii) allowing
fraudulent transactions to be successfully processed if there is no
step-up challenge of a card-not-present transaction; (iii) consumer
inconvenience during card-not-present transactions based at least
in part on having to answer an additional authentication challenge
during a transaction; (iv) abandonment of transactions by consumers
when faced with a step-up challenge, thus leading to lost sales for
merchants and lost processing fees for the other network parties
based on those abandoned transactions; (v) unavailability of
customizable fraud-related services to merchants and/or merchant
acquirers; (vi) increased risk with merchant liability for
fraudulent transactions; (vii) digital wallet-related fraud; (viii)
issuers having limited access to some data that may be used to
fraud-score transactions; (ix) reducing the network load by
reducing network traffic to and from the ACS; (x) increasing the
speed of the authentication process by reducing the number of steps
required; (xi) reducing the processing load of the ACS by
pre-filtering authentication requests to prevent redundant or
unnecessary processing; (xii) improved transaction approval
rates.
[0057] A technical effect of the systems and processes described
herein is achieved by performing at least one of the following
steps: (i) receive an authentication request message for a
transaction, the authentication request message including
authentication data; (ii) extract the authentication data from the
authentication request message; (iii) determine if the ACS is
available to process the transaction; (iv) if the ACS is
unavailable, the at least one processor programmed to: (a)
generate, based at least in part on the extracted authentication
data, risk-based authentication (RBA) result data including a risk
score and at least one reason code that indicates at least one
factor that influenced the generated risk score; (b) compare the
authentication data to at least one long term variable and at least
one short term variable, wherein the at least one long term
variable includes historical authentication data and historical
authorization data; and (c) transmit an authentication response
message based on the RBA result data; (v) determine that the online
user is not associated with the ACS based on the extracted
authentication data; (vi) generate an authentication decision based
on the RBA result data; (vii) determine a risk level based on the
RBA result data; (viii) embed an indicator in the authentication
response message indicating that the transaction is fully
authenticated if the risk level is low; (ix) embed one or more
indicators in the authentication response message indicating that
the transaction is a merchant only transaction and that
authentication was attempted if the risk level is not low; (x)
determine whether the authentication request message complies with
the 3DS 2 Protocol or subsequent versions of the 3DS Protocol; and
(xi) bypass determining if the ACS is available if the
authentication request message does not comply.
[0058] In some embodiment, a further technical effect is achieved
by performing at least one of the following steps: (i) transmit the
authentication request message to the ACS; (ii) wait a
predetermined period of time for a response from the ACS; (iii)
determine that the ACS is unavailable if no response is received
after the predetermined period of time; and (iv) receive a response
from the ACS, wherein the response indicates at least one of the
online user is not enrolled with the ACS, the ACS is currently
unavailable, and the ACS was unable to authenticate the online
user.
[0059] In some embodiments, an additional technical effect is
achieved by performing at least one of the following steps: (i)
receive an authentication request message for a transaction
involving a market regulated by a regulatory entity, the
authentication request message including authentication data and a
transaction value; (ii) extract the authentication data from the
authentication request message; (iii) generate, based at least in
part on the extracted authentication data, risk-based
authentication (RBA) result data including a risk score for the
transaction; (iv) determine that a risk of fraud in the transaction
is below a regulated risk threshold established by the regulatory
entity by comparing the risk score to the regulated risk threshold;
(v) determine that the transaction value is below a transaction
limit set by the regulatory entity, the transaction limit
identifies a threshold transaction below which strong consumer
authentication may be avoided for transactions below the regulated
risk threshold; and (vi) transmit an authentication response
message authenticating the transaction based on the determined risk
of fraud being below the regulated risk threshold and further based
on the determined transaction value being below the transaction
limit without strong consumer authentication having been performed
on the transaction.
[0060] As will be appreciated, based on the description herein the
technical improvement in the authentication system as described
herein is a computer-based solution to a technical deficiency or
problem that is itself rooted in computer technology (e.g., the
problem itself derives from the use of computer technology). More
specifically, fraud is significant problem for transactions
conducted over an electronic payment network, especially for
card-not-present transactions. Advanced fraud detection
methodologies (e.g., RBA) exist, but at least some ACSs are unable
to execute those methodologies and furthermore communication with
ACSs increases network traffic and processing load, and in addition
the ACS may be unavailable. Accordingly, to address this problem,
the systems and methods described herein address this technical
problem by using an RBA-enabled directory server and RBA engine to
perform RBA and filter the results to determine which
authentications need to be forwarded to an ACS and to forward the
results of the RBA to the ACS to enable the ACS to make an
authentication decision.
[0061] The following detailed description of the embodiments of the
disclosure refers to the accompanying drawings. The same reference
numbers in different drawings may identify the same or similar
elements. Also, the following detailed description does not limit
the claims.
[0062] Described herein are computer systems such as authentication
computer systems. As described herein, all such computer systems
include a processor and a memory. However, any processor in a
computer device referred to herein may also refer to one or more
processors wherein the processor may be in one computing device or
a plurality of computing devices acting in parallel. Additionally,
any memory in a computer device referred to herein may also refer
to one or more memories wherein the memories may be in one
computing device or a plurality of computing devices acting in
parallel.
[0063] As used herein, a processor may include any programmable
system including systems using micro-controllers, reduced
instruction set circuits (RISC), application specific integrated
circuits (ASICs), logic circuits, and any other circuit or
processor capable of executing the functions described herein. The
above examples are example only, and are thus not intended to limit
in any way the definition and/or meaning of the term
"processor."
[0064] As used herein, the term "database" may refer to either a
body of data, a relational database management system (RDBMS), or
to both. As used herein, a database may include any collection of
data including hierarchical databases, relational databases, flat
file databases, object-relational databases, object oriented
databases, and any other structured collection of records or data
that is stored in a computer system. The above examples are example
only, and thus are not intended to limit in any way the definition
and/or meaning of the term database. Examples of RDBMS's include,
but are not limited to including, Oracle.RTM. Database, MySQL,
IBM.RTM. DB2, Microsoft.RTM. SQL Server, Sybase.RTM., and
PostgreSQL. However, any database may be used that enables the
systems and methods described herein. (Oracle is a registered
trademark of Oracle Corporation, Redwood Shores, Calif.; IBM is a
registered trademark of International Business Machines
Corporation, Armonk, N.Y.; Microsoft is a registered trademark of
Microsoft Corporation, Redmond, Wash.; and Sybase is a registered
trademark of Sybase, Dublin, Calif.)
[0065] In one embodiment, a computer program is provided, and the
program is embodied on a computer readable medium. In an example
embodiment, the system is executed on a single computer system,
without requiring a connection to a sever computer. In a further
embodiment, the system is being run in a Windows.RTM. environment
(Windows is a registered trademark of Microsoft Corporation,
Redmond, Wash.). In yet another embodiment, the system is run on a
mainframe environment and a UNIX.RTM. server environment (UNIX is a
registered trademark of X/Open Company Limited located in Reading,
Berkshire, United Kingdom). In a further embodiment, the system is
run on an iOS.RTM. environment (iOS is a registered trademark of
Cisco Systems, Inc. located in San Jose, Calif.). In yet a further
embodiment, the system is run on a Mac OS.RTM. environment (Mac OS
is a registered trademark of Apple Inc. located in Cupertino,
Calif.). In still yet a further embodiment, the system is run on
Android.RTM. OS (Android is a registered trademark of Google, Inc.
of Mountain View, Calif.). In another embodiment, the system is run
on Linux.RTM. OS (Linux is a registered trademark of Linus Torvalds
of Boston, Mass.). The application is flexible and designed to run
in various different environments without compromising any major
functionality. In some embodiments, the system includes multiple
components distributed among a plurality of computing devices. One
or more components may be in the form of computer-executable
instructions embodied in a computer-readable medium.
[0066] As used herein, an element or step recited in the singular
and proceeded with the word "a" or "an" should be understood as not
excluding plural elements or steps, unless such exclusion is
explicitly recited. Furthermore, references to "example embodiment"
or "one embodiment" of the present disclosure are not intended to
be interpreted as excluding the existence of additional embodiments
that also incorporate the recited features.
[0067] As used herein, the terms "software" and "firmware" are
interchangeable, and include any computer program stored in memory
for execution by a processor, including RAM memory, ROM memory,
EPROM memory, EEPROM memory, and non-volatile RAM (NVRAM) memory.
The above memory types are example only, and are thus not limiting
as to the types of memory usable for storage of a computer
program.
[0068] As used herein, the terms "payment device," "transaction
card," "financial transaction card," and "payment card" refer to
any suitable transaction card, such as a credit card, a debit card,
a prepaid card, a charge card, a membership card, a promotional
card, a frequent flyer card, an identification card, a prepaid
card, a gift card, and/or any other device that may hold payment
account information, such as mobile phones, Smartphones, personal
digital assistants (PDAs), wearable computing devices, key fobs,
and/or any other computing devices capable of providing account
information. Moreover, these terms may refer to payments made
directly from or using bank accounts, stored valued accounts,
mobile wallets, etc., and accordingly are not limited to physical
devices but rather refer generally to payment credentials. Each
type of payment device can be used as a method of payment for
performing a transaction. In addition, consumer card account
behavior can include but is not limited to purchases, management
activities (e.g., balance checking), bill payments, achievement of
targets (meeting account balance goals, paying bills on time),
and/or product registrations (e.g., mobile application
downloads).
[0069] The systems and processes are not limited to the specific
embodiments described herein. In addition, components of each
system and each process can be practiced independent and separate
from other components and processes described herein. Each
component and process also can be used in combination with other
assembly packages and processes.
[0070] The following detailed description illustrates embodiments
of the disclosure by way of example and not by way of limitation.
It is contemplated that the disclosure has general application to
authenticating users for transactions conducted over an electronic
payment network.
[0071] FIG. 1 is a schematic diagram illustrating an example RBA
platform 34 in communication with a multi-party payment card system
20 for processing payment transactions in accordance with one
embodiment of the present disclosure. FIG. 1 depicts a flow of data
in a financial transaction through system 20. Embodiments described
herein may relate to a transaction card system, such as a credit
card payment system using the MASTERCARD.RTM. interchange network.
The MASTERCARD.RTM. interchange network is a set of proprietary
communications standards promulgated by Mastercard International
Incorporated.RTM. for the exchange of financial transaction data
and the settlement of funds between financial institutions that are
members of Mastercard International Incorporated.RTM..
(MASTERCARD.RTM. is a registered trademark of Mastercard
International Incorporated located in Purchase, N.Y.).
[0072] In the exemplary transaction card system, a financial
institution called the "issuer" issues a transaction card, such as
a credit card, to a consumer or cardholder 22, who uses the
transaction card to tender payment for a purchase from a merchant
24. Cardholder 22 may purchase goods and services ("products") at
merchant 24. Cardholder 22 may make such purchases using virtual
forms of the transaction card and, more specifically, by providing
data related to the transaction card (e.g., the transaction card
number, expiration date, associated postal code, and security code)
to initiate transactions. To accept payment with the transaction
card or virtual forms of the transaction card, merchant 24 must
normally establish an account with a financial institution that is
part of the financial payment system. This financial institution is
usually called the "merchant bank," the "acquiring bank," or the
"acquirer." When cardholder 22 tenders payment for a purchase with
a transaction card or virtual transaction card, merchant 24
requests authentication of the cardholder 22 and authorization from
a merchant bank 26 for the amount of the purchase. The request may
be performed over the telephone or electronically, but is usually
performed through the use of a point-of-sale terminal, which reads
cardholder's 22 account information from a magnetic stripe, a chip,
or embossed characters on the transaction card and communicates
electronically with the transaction processing computers of
merchant bank 26. Merchant 24 receives cardholder's 22 account
information as provided by cardholder 22. Alternatively, merchant
bank 26 may authorize a third party to perform transaction
processing on its behalf. In this case, the point-of-sale terminal
will be configured to communicate with the third party. Such a
third party is usually called a "merchant processor," an "acquiring
processor," or a "third party processor."
[0073] Using an interchange network 28, computers of merchant bank
26 or merchant processor will communicate with computers of an
issuer bank 30 to determine whether the alleged cardholder is
actually legitimate cardholder 22 (i.e., authentication), whether
cardholder's 22 account 32 is in good standing, and whether the
purchase is covered by cardholder's 22 available credit line. Based
on these determinations, the requests for authentication and
authorization will be declined or accepted. Authentication may be
performed prior to authorization. If the requests are accepted, an
authorization code is issued to merchant 24.
[0074] In the exemplary embodiment, the payment card system 20
includes or is in communication with a risk-based authentication
(RBA) platform 34. In this embodiment, the RBA platform 34 provides
enhanced meta-data collection to capture information, including
meta-data from the payment transactions processed by the payment
card system 20. The RBA platform 34 stores this meta-data to use to
provide as historical data when performing an authentication
process prior to performing an authorization process. In the
exemplary embodiment, the RBA platform 34 may receive historical
data from one or more of the acquirer bank 26, the interchange
network 28, and the issuer bank 30. Examples of this data include
one or more long term variables ("LTV"). The one or more LTV may
include historical authorization data associated with a plurality
of PANs, other historical data associated with the plurality of
PANs, etc. The LTV may be associated with both card present and
card not present historical transactions. For example, the LTV may
include cardholder shipping address, cardholder billing address,
cardholder email address, cardholder phone number, merchant name,
merchant category, merchant location, and/or at least one
environment-related variable (e.g., device details, browser
details) including device ID, IP address, device channel, etc.
Further, the LTV may be stored in a database accessible by RBA
platform 34 and operated by an interchange network 28. In some
embodiments, the LTV data will be hashed prior to storing to
protect the security of this personally identifiable
information.
[0075] When a request for authorization is accepted, the available
credit line of cardholder's 22 account 32 is decreased. Normally, a
charge for a payment card transaction is not posted immediately to
cardholder's 22 account 32 because bankcard associations, such as
Mastercard International Incorporated.RTM., have promulgated rules
that do not allow merchant 24 to charge, or "capture," a
transaction until products are shipped or services are delivered.
However, with respect to at least some debit card transactions, a
charge may be posted at the time of the transaction. When merchant
24 ships or delivers the products or services, merchant 24 captures
the transaction by, for example, appropriate data entry procedures
on the point-of-sale terminal. This may include bundling of
approved transactions daily for standard retail purchases. If
cardholder 22 cancels a transaction before it is captured, a "void"
is generated. If cardholder 22 returns products after the
transaction has been captured, a "credit" is generated. Interchange
network 28 and/or issuer bank 30 stores the transaction card
information, such as a type of merchant, amount of purchase, date
of purchase, in a database 120 (shown in FIG. 2).
[0076] After a purchase has been made, a clearing process occurs to
transfer additional transaction data related to the purchase among
the parties to the transaction, such as merchant bank 26,
interchange network 28, and issuer bank 30. More specifically,
during and/or after the clearing process, additional data, such as
a time of purchase, a merchant name, a type of merchant, purchase
information, cardholder account information, a type of transaction,
information regarding the purchased item and/or service, and/or
other suitable information, is associated with a transaction and
transmitted between parties to the transaction as transaction data,
and may be stored by any of the parties to the transaction. After a
transaction is authorized and cleared, the transaction is settled
among merchant 24, merchant bank 26, and issuer bank 30. Settlement
refers to the transfer of financial data or funds among merchant's
24 account, merchant bank 26, and issuer bank 30 related to the
transaction. Usually, transactions are captured and accumulated
into a "batch," which is settled as a group. More specifically, a
transaction may be settled between issuer bank 30 and interchange
network 28, and then between interchange network 28 and merchant
bank 26, and then between merchant bank 26 and merchant 24.
[0077] As described below in more detail, risk-based authentication
(RBA) may be performed by the RBA platform 34 on behalf of an
access control server (ACS) or issuer bank 30 in the context of
multi-party payment card system 20. Although the systems described
herein are not intended to be limited to facilitate such
applications, the systems are described as such for example
purposes.
[0078] FIG. 2 is an expanded block diagram of an example embodiment
of a computer system 100 used in authenticating payment
transactions. In the exemplary embodiment, system 100 may be used
for authenticating payment transactions either in concert with an
ACS or in place of the ACS.
[0079] In the exemplary embodiment, cardholder computing devices
102 are computers that include a web browser or a software
application, which enables cardholder computing devices 102 to
access remote computer devices, such as merchant website 104, using
the Internet or other network. More specifically, cardholder
computing devices 102 may be communicatively coupled to the
Internet through many interfaces including, but not limited to, at
least one of a network, such as the Internet, a local area network
(LAN), a wide area network (WAN), or an integrated services digital
network (ISDN), a dial-up-connection, a digital subscriber line
(DSL), a cellular phone connection, and a cable modem. Cardholder
computing devices 102 may be any device capable of accessing the
Internet including, but not limited to, a desktop computer, a
laptop computer, a personal digital assistant (PDA), a cellular
phone, a smartphone, a tablet, a phablet, wearable electronics,
smart watch, or other web-based connectable equipment or mobile
devices. In the exemplary embodiment, cardholder computing devices
102 are associated with individual cardholders 22 (shown in FIG.
1).
[0080] In the exemplary embodiment, merchant website 104 is an
online shopping website that is reachable through computers that
include a web browser or a software application, such as cardholder
computing devices 102, using the Internet or other network. More
specifically, merchant website 104 may be hosted on one or more
computers that are communicatively coupled to the Internet through
many interfaces including, but not limited to, at least one of a
network, such as the Internet, a local area network (LAN), a wide
area network (WAN), or an integrated services digital network
(ISDN), a dial-up-connection, a digital subscriber line (DSL), a
cellular phone connection, and a cable modem. Computing devices
hosting merchant website 104 may be any device capable of accessing
the Internet including, but not limited to, a desktop computer, a
laptop computer, a personal digital assistant (PDA), a cellular
phone, a smartphone, a tablet, a phablet, wearable electronics,
smart watch, or other web-based connectable equipment or mobile
devices. In the exemplary embodiment, merchant website 104 is
associated with merchant 24 (shown in FIG. 1). In the exemplary
embodiment, merchant website 104 allows cardholder 22 to purchase
goods and/or services using cardholder computing device 102. In
some embodiments, payment transactions performed through merchant
website 104 are considered card not present transactions.
[0081] In the exemplary embodiment, data gathering computer devices
106 are computers that include a web browser or a software
application, which enables data gathering computer devices 106 to
access remote computer devices, such as merchant website 104 and
authentication server 112, using the Internet or other network.
More specifically, data gathering computing devices 106 may be
communicatively coupled to the Internet through many interfaces
including, but not limited to, at least one of a network, such as
the Internet, a local area network (LAN), a wide area network
(WAN), or an integrated services digital network (ISDN), a
dial-up-connection, a digital subscriber line (DSL), a cellular
phone connection, and a cable modem. Data gathering computer
devices 106 may be any device capable of accessing the Internet
including, but not limited to, a desktop computer, a laptop
computer, a personal digital assistant (PDA), a cellular phone, a
smartphone, a tablet, a phablet, wearable electronics, smart watch,
or other web-based connectable equipment or mobile devices. In some
embodiments, the data gathering computer devices 106 are associated
with a 3DS server or service. In other embodiments, data gathering
computer devices 106 are associated with acquirer bank 26 (shown in
FIG. 1).
[0082] In the exemplary embodiments, authentication server 112 is
in communication with a plurality of data gathering computer
devices 106 and one or more access control servers (ACS) 108. In
some embodiments, authentication server 112 is similar to RBA
platform 34 (shown in FIG. 1). In the exemplary embodiment,
authentication server 112 receives data from data gathering
computer device 106 and uses that data to perform authentication of
payment transactions. In some embodiments, authentication server
112 performs authentication with ACS 108. In other embodiments,
authentication server 112 replaces the ACS 108 in the
authentication process. In the exemplary embodiment, authentication
server 112 is associated with the interchange network 28 (shown in
FIG. 1). In other embodiments, the authentication server 112 is
merely in communication with the interchange network 28.
[0083] In the exemplary embodiment, issuer computing devices 110
are computers that include a web browser or a software application,
which enables issuer computing devices 110 to access remote
computer devices, such as ACS 108 and authentication server 112,
using the Internet or other network. More specifically, issuer
computing devices 110 may be communicatively coupled to the
Internet through many interfaces including, but not limited to, at
least one of a network, such as the Internet, a local area network
(LAN), a wide area network (WAN), or an integrated services digital
network (ISDN), a dial-up-connection, a digital subscriber line
(DSL), a cellular phone connection, and a cable modem. Issuer
computing devices 110 may be any device capable of accessing the
Internet including, but not limited to, a desktop computer, a
laptop computer, a personal digital assistant (PDA), a cellular
phone, a smartphone, a tablet, a phablet, wearable electronics,
smart watch, or other web-based connectable equipment or mobile
devices. In the exemplary embodiment, issuer computing devices 110
are associated with the issuer bank 30 (shown in FIG. 1).
[0084] A database server 116 is connected to database 120. In one
embodiment, centralized database 120 is stored on server system 112
and can be accessed by potential users at one of client systems
(not shown) by logging onto authentication server 112 through one
of client systems. In an alternative embodiment, database 120 is
stored remotely from authentication server 112 and may be
non-centralized. Database 120 may be a database configured to store
information used by authentication server 112 including, for
example, historical payment transaction records.
[0085] Database 120 may include a single database having separated
sections or partitions, or may include multiple databases, each
being separate from each other. Database 120 may store transaction
data generated over the processing network including data relating
to merchants, consumers, account holders, prospective customers,
issuers, acquirers, and/or purchases made. Database 120 may also
store account data including at least one of a cardholder name, a
cardholder address, an account number, other account identifiers,
and transaction information. Database 120 may also store merchant
information including a merchant identifier that identifies each
merchant registered to use the network, and instructions for
settling transactions including merchant bank account information.
Database 120 may also store purchase data associated with items
being purchased by a cardholder from a merchant, and authentication
and authorization request data. Database 120 may store one or more
authentication profiles, where each authentication profile includes
one or more authentication rules, one or more risk level
thresholds, and one or more routing rules based on the risk level
thresholds.
[0086] FIG. 3 illustrates an example configuration of a server
system 301 such as RBA platform 34 (shown in FIG. 1), in accordance
with one example embodiment of the present disclosure. Server
system 301 may also include, but is not limited to, merchant
website 104, data gathering computer device 106, ACS 108, issuer
computing device 110, authentication server 112, and database
server 116 (all shown in FIG. 2). In the example embodiment, server
system 301 determines and analyzes characteristics of devices used
in payment transactions, as described below.
[0087] Server system 301 includes a processor 305 for executing
instructions. Instructions may be stored in a memory area 310, for
example. Processor 305 may include one or more processing units
(e.g., in a multi-core configuration) for executing instructions.
The instructions may be executed within a variety of different
operating systems on the server system 301, such as UNIX, LINUX,
Microsoft Windows.RTM., etc. It should also be appreciated that
upon initiation of a computer-based method, various instructions
may be executed during initialization. Some operations may be
required in order to perform one or more processes described
herein, while other operations may be more general and/or specific
to a particular programming language (e.g., C, C#, C++, Java, or
other suitable programming languages, etc.).
[0088] Processor 305 is operatively coupled to a communication
interface 315 such that server system 301 is capable of
communicating with a remote device such as a user system or another
server system 301. For example, communication interface 315 may
receive requests from a client system (not shown) via the Internet,
as illustrated in FIG. 2.
[0089] Processor 305 may also be operatively coupled to a storage
device 334. Storage device 334 is any computer-operated hardware
suitable for storing and/or retrieving data. In some embodiments,
storage device 334 is integrated in server system 301. For example,
server system 301 may include one or more hard disk drives as
storage device 334. In other embodiments, storage device 334 is
external to server system 301 and may be accessed by a plurality of
server systems 301. For example, storage device 334 may include
multiple storage units such as hard disks or solid state disks in a
redundant array of inexpensive disks (RAID) configuration. Storage
device 334 may include a storage area network (SAN) and/or a
network attached storage (NAS) system.
[0090] In some embodiments, processor 305 is operatively coupled to
storage device 334 via a storage interface 320. Storage interface
320 is any component capable of providing processor 305 with access
to storage device 334. Storage interface 320 may include, for
example, an Advanced Technology Attachment (ATA) adapter, a Serial
ATA (SATA) adapter, a Small Computer System Interface (SCSI)
adapter, a RAID controller, a SAN adapter, a network adapter,
and/or any component providing processor 305 with access to storage
device 334.
[0091] Memory area 310 may include, but are not limited to, random
access memory (RAM) such as dynamic RAM (DRAM) or static RAM
(SRAM), read-only memory (ROM), erasable programmable read-only
memory (EPROM), electrically erasable programmable read-only memory
(EEPROM), and non-volatile RAM (NVRAM). The above memory types are
examples only, and are thus not limiting as to the types of memory
usable for storage of a computer program.
[0092] FIG. 4 illustrates an example configuration of a client
computing device 402. Client computing device 402 may include, but
is not limited to, cardholder computing device 102 (shown in FIG.
1). Client computing device 402 includes a processor 404 for
executing instructions. In some embodiments, executable
instructions are stored in a memory area 406. Processor 404 may
include one or more processing units (e.g., in a multi-core
configuration). Memory area 406 is any device allowing information
such as executable instructions and/or other data to be stored and
retrieved. Memory area 406 may include one or more
computer-readable media.
[0093] Client computing device 402 also includes at least one media
output component 408 for presenting information to a user 400.
Media output component 408 is any component capable of conveying
information to user 400. In some embodiments, media output
component 408 includes an output adapter such as a video adapter
and/or an audio adapter. An output adapter is operatively coupled
to processor 404 and operatively couplable to an output device such
as a display device (e.g., a liquid crystal display (LCD), organic
light emitting diode (OLED) display, cathode ray tube (CRT), or
"electronic ink" display) or an audio output device (e.g., a
speaker or headphones).
[0094] In some embodiments, client computing device 402 includes an
input device 410 for receiving input from user 400. Input device
410 may include, for example, a keyboard, a pointing device, a
mouse, a stylus, a touch sensitive panel (e.g., a touch pad or a
touch screen), a camera, a gyroscope, an accelerometer, a position
detector, and/or an audio input device. A single component such as
a touch screen may function as both an output device of media
output component 408 and input device 410.
[0095] Client computing device 402 may also include a communication
interface 412, which is communicatively couplable to a remote
device such as server system 301 or a web server operated by a
merchant. Communication interface 412 may include, for example, a
wired or wireless network adapter or a wireless data transceiver
for use with a mobile phone network (e.g., Global System for Mobile
communications (GSM), 3G, 4G or Bluetooth) or other mobile data
network (e.g., Worldwide Interoperability for Microwave Access
(WIMAX)).
[0096] FIG. 5 is a schematic diagram illustrating transaction flow
in an example authentication system 500 that uses the 3DS 2
Protocol (or subsequent versions of the 3DS Protocol) for
authentication. Information regarding the 3DS Protocol, including
the current version of the protocol, can be found at
https://www.emvco.com. System 500 includes a directory server 510
that facilitates authenticating a cardholder for a transaction, as
described herein. Directory server 510 may be operated, for
example, by interchange network 28 (shown in FIG. 1).
[0097] A cardholder (e.g., cardholder 22, shown in FIG. 1)
initiates a transaction (e.g., an online transaction) on a
cardholder computing device 102 (shown in FIG. 2), such as, for
example, a mobile computing device. During initiation of the
transaction, the cardholder provides authentication data that will
ultimately be used to authenticate the cardholder. In the exemplary
embodiment, this authentication data includes form data that the
cardholder fills in to make the purchase and scraped data, which is
data about the cardholder, such as device details and browser
details including device ID, IP address, device channel, etc.
[0098] The authentication data is transmitted from the cardholder
computing device 102 to a 3DS client 502 within a 3DS requestor
environment 504. The 3DS client 502 may be operated by a merchant
(e.g., merchant 24, shown in FIG. 1). In some embodiments, 3DS
client 502 is a part of merchant website 104 (shown in FIG. 2). 3DS
client 502 collects, from the cardholder computing device 102,
information necessary to authenticate the cardholder using the 3DS
2 Protocol, including the authentication data.
[0099] The 3DS client 502 collects information (including the
authentication data) and transmits the collected information to a
3DS server 506 for inclusion in an authentication request message,
also referred to herein as an AReq message. 3DS client 502 is also
part of the 3DS requestor environment 504. 3DS client 502 and 3DS
server 506 may communicate with one another, for example, using
application programming interfaces (APIs) or browser interactions.
In some embodiments, the 3DS server 506 is similar to data
gathering computer device 106 (shown in FIG. 2).
[0100] Using the authentication data provided by the cardholder and
other data collected within 3DS requestor environment 504, the 3DS
server 506 generates the AReq message and transmits the AReq
message to directory server 510, based on the payment processor
associated with the transaction card being used in the transaction.
In some embodiments, the directory server 510 is similar to the
authentication server 112 (shown in FIG. 2). That is, different
payment processors will generally have different directory servers
for processing transactions. When generating the AReq message, 3DS
server 506 formats the data for security purposes. In this
embodiment, directory server 510 forwards the AReq message to an
appropriate access control server (ACS) 512, based on the issuer of
the payment card. In some embodiments, ACS 512 is similar to ACS
108 (shown in FIG. 2)
[0101] ACS 512 determines, based on the AReq message, whether
authentication is required. Further, ACS 512 facilitates ensuring
that any required authentication is properly carried out. ACS 512
performs these authentication operations on behalf of an issuer
operating an issuer computing device 514.
[0102] In response to the AReq message, ACS 512 returns an
authentication response (ARes) message to directory server 510,
which directory server 510 in turn forwards to 3DS server 506.
Before returning the ARes message, ACS 512 evaluates the data in
the AReq message and performs risk-based authentication (RBA) on
the transaction. Specifically, when ACS 512 determines that an
explicit cardholder step-up authentication is not required (i.e.,
when the transaction is determined to be low risk), ACS 512
determines authentication is complete and returns an ARes
indicating the same. If, however, ACS 512 determines that
cardholder step-up authentication is required, ACS 512 initiates a
step-up challenge request. The results of the step-up challenge
requests are transmitted (in the ARes message), to 3DS server 506
(via directory server 510), and ultimately to the cardholder. If
step-up authentication is required, ACS 512 controls the step-up
authentication in accordance with methods used for cardholders of
the issuer (e.g., biometric authentication, one time password (OTP)
authentication, short message service (SMS) authentication, etc.).
A 3DS requestor 516 included in 3DS requestor environment 504
controls how the various components interact with one another in
the example embodiment.
[0103] After the authentication process is complete (i.e., after
the 3DS Protocol is finished), if the cardholder is successfully
authenticated, payment authorization for the transaction is
undertaken. That is, the authentication using the 3DS 2 Protocol
(or subsequent versions of the 3DS Protocol) occurs before payment
authorization for the transaction.
[0104] For payment authorization, the merchant (e.g., using 3DS
server 506) exchanges authorization data with an acquirer computing
device 520 operated by an acquirer, such as merchant bank 26 (shown
in FIG. 1) and a payment network 522, such as interchange network
28 (shown in FIG. 1). If appropriate, the merchant, acquirer, or
payment network may submit an authorization request including
information that indicates authentication occurred. Acquirer
computing device 520 then processes the authorization with issuer
computing device 514 and returns the authorization results to the
merchant.
[0105] The 3DS 2 Protocol (and subsequent versions of the 3DS
Protocol) provides a number of benefits to cardholders, issuers,
and merchants. It reduces risk of unauthorized transactions through
an approach that incorporates a rich, comprehensive set of data to
make authentication decisions. For cardholders, it provides a
simple, secure, and familiar online authentication experience,
regardless of payment channel or device. For issuers, it allows for
"frictionless" authentication, in which an explicit cardholder
step-up authentication is not required or performed. This enables
more intelligent risk assessment decisions and the ability to
selectively challenge the cardholder as needed. This also improves
cardholder experience and overall cardholder loyalty to issuers.
For merchants, the 3DS 2 Protocol decreases fraud on all
authenticated transactions, and increases revenue potential from
reduced friction and reduced cart abandonment (i.e., cardholders
deciding not to complete a transaction after they have already
selected one or more items to be purchased), especially for mobile
payment channels. This also improves cardholder experience and
overall cardholder loyalty to merchants.
[0106] Using 3DS 2 Protocol (or subsequent versions of the 3DS
Protocol), payment networks see 100% of all authentication requests
globally on all cards on their brands. No other party, including
issuers and ACS providers, is able to provide this global
visibility. This global visibility may be leveraged to provide a
consistent, standards-based risk analysis of transactions on behalf
of issuers, enabling a market-wide risk-based authentication
approach.
[0107] As compared to previous authentication methods (e.g., 3DS
1.0), the 3DS 2 Protocol (and subsequent versions of the 3DS
Protocol) allows for approximately ten times the amount of
transaction data to be gathered, analyzed, and utilized to prevent
fraud. The additional data included in the 3DS Protocol increases
data exchange between merchants and issuers, and improves
risk-based authentication (RBA) decisioning. RBA allows issuers to
examine every authentication request through transaction risk
analysis, while focusing fraud prevention efforts on transactions
that prevent the most risk. Further, RBA utilizes both behavioral
and transactional inputs in conjunction with a risk engine to
determine riskiness of a transaction.
[0108] Transactions deemed safe or low risk are silently
authenticated (i.e., so-called "frictionless" authentication),
while higher risk transactions are subjected to step-up
authentication. When a low risk transaction is silently
authenticated, so much data has already been gathered that further
authentication adds little to no value. Accordingly, RBA
effectively replaces the need for an explicit interaction with the
cardholder for every transaction, but transactions are still fully
authenticated, with liability resting with the issuer. Thus, more
transactions are completed with minimal cardholder disruption,
aiding e-commerce growth.
[0109] One goal of RBA is to minimize the number of transactions
that require active (i.e., step-up) authentication, while keeping
fraud to a minimum and improving consumer friction points during
the transaction process. With RBA, the information gathered enables
transaction scoring and classification into low, medium, and high
risk, allowing the issuer and ACS 512 to take appropriate
action.
[0110] The 3DS 2 Protocol (and subsequent versions of the 3DS
Protocol) enables a market-wide level risk analysis of all
transactions that reach directory server 510. Each transaction can
be scored and/or flagged based on the global data available using
the 3DS 2 Protocol (and subsequent versions of the 3DS Protocol).
Additionally, the payment processor operating the directory server
510 has the ability to see cardholder activity across the digital
and physical domains, and can utilize this expanded view to improve
scoring. In contrast, traditional authentication service providers
may only address the digital domain. For example, a payment
processor could indicate if a particular device is associated with
fraud, and flag that device for issuers in future transactions. The
issuer may then reject transactions involving that device or prompt
for additional authentication (e.g., through two-factor
authentication).
[0111] The following Table 2 lists a number of the data elements
that are used in the 3DS 2 Protocol for authentication. For
example, at least some of these data elements may be included in
the authentication data included in the AReq sent to directory
server 510. The eighteen data elements that are also part of the
3DS 1.0 Protocol are bolded in Table 2. Those of skill in the art
will appreciate that the number of rich data elements could grow
beyond those listed below (e.g., in future versions of the 3DS
Protocol), and could include over one hundred and seventy data
elements. Further, an app-based transaction (e.g., carried out
using a mobile computing device) could provide even more data
elements than browser-based transactions. In addition, a
transaction performed using an Android device could have over one
hundred and thirty additional elements.
TABLE-US-00003 TABLE 2 Data Element 1 3DS Requestor Authentication
Information 2 3DS Requestor Challenge Indicator 3 3DS Requestor ID
4 3DS Requestor Initiated Indicator 5 3DS Requestor Name 6 3DS
Requestor Non-Payment Authentication Indicator 7 3DS Requestor
Prior Transaction Authentication Information 8 3DS Requestor URL 9
3DS Server Operator ID 10 3DS Server Reference Number 11 3DS Server
Transaction ID 12 3DS Server URL 13 Account Type 14 Acquirer BIN 15
Acquirer Merchant ID 16 ACS Challenge Mandated Indicator 17 ACS
Counter ACS to SDK 18 ACS HTML 19 ACS Operator ID 20 ACS Reference
Number 21 ACS Rendering Type 22 ACS Signed Content 23 ACS
Transaction ID 24 ACS UI Type 25 Address Match Indicator 26
Authentication Method 27 Authentication Type 28 Authentication
Value 29 Browser Accept Headers 30 Browser IP Address 31 Browser
Java Enabled 32 Browser Language 33 Browser Screen Color Depth 34
Browser Screen Height 35 Browser Screen Width 36 Browser Time Zone
37 Browser User-Agent 38 Card/Token Expiry Date 39 Cardholder
Account Identifier 40 Cardholder Account Information 41 Cardholder
Account Number 42 Cardholder Billing Address City 43 Cardholder
Billing Address Country 44 Cardholder Billing Address Line 1 45
Cardholder Billing Address Line 2 46 Cardholder Billing Address
Line 3 47 Cardholder Billing Address Postal Code 48 Cardholder
Billing Address State 49 Cardholder Email Address 50 Cardholder
Home Phone Number 51 Cardholder Mobile Phone Number 52 Cardholder
Name 53 Cardholder Shipping Address City 54 Cardholder Shipping
Address Country 55 Cardholder Shipping Address Line 1 56 Cardholder
Shipping Address Line 2 57 Cardholder Shipping Address Line 3 58
Cardholder Shipping Address Postal Code 59 Cardholder Shipping
Address State 60 Cardholder Work Phone Number 61 Challenge
Additional Information Text 62 Challenge Cancelation Indicator 63
Challenge Data Entry 64 Challenge HTML Data Entry 65 Challenge
Information Header 66 Challenge Information Label 67 Challenge
Information Text 68 Challenge Information Text Indicator 69
Challenge Selection Information 70 Challenge Window Size 71 Device
Channel 72 Device Information 73 Device Rendering Options Supported
74 DS Reference Number 75 DS Transaction ID 76 DS URL 77 Electronic
Commerce Indicator 78 EMV Payment Token Indicator 79 Expandable
Information Label 1 80 Expandable Information Text 1 81 Instalment
Payment Data 82 Interaction Counter 83 Issuer Image 84 Merchant
Category Code 85 Merchant Country Code 86 Merchant Name 87 Merchant
Risk Indicator 88 Message Category 89 Message Extension 90 Message
Type 91 Message Version Number 92 Notification URL 93 OOB App Label
94 OOB App URL 95 OOB Continuation Indicator 96 OOB Continuation
Label 97 Payment System Image 98 Purchase Amount 99 Purchase
Currency 100 Purchase Currency Exponent 101 Purchase Date &
Time 102 Recurring Expiry 103 Recurring Frequency 104 Resend
Challenge Information Code 105 Resend Information Label 106 Results
Message Status 107 SDK App ID 108 SDK Counter SDK to ACS 109 SDK
Encrypted Data 110 SDK Ephemeral Public Key (Qc) 111 SDK Reference
Number 112 SDK Transaction ID 113 Submit Authentication Label 114
Transaction Status 115 Transaction Status Reason 116 Transaction
Type 117 Why Information Label 118 Why Information Text
[0112] As explained above, in the embodiment shown in FIG. 5, ACS
512 performs authentication using RBA capabilities. However, many
ACS providers that are issuer processors for authentication do not
have RBA capabilities. Further, ACS providers with RBA capabilities
may temporarily lose those capabilities (e.g., due to equipment
malfunction). In light of the above-described advantages of the 3DS
2 Protocol (and subsequent versions of the 3DS Protocol), ACS
providers without RBA capabilities risk losing customers to other
ACS providers that have this capability. Accordingly, it would be
desirable to facilitate 3DS 2 Protocol (and subsequent versions of
the 3DS Protocol) authentication for ACS providers that do not have
RBA capabilities.
[0113] FIG. 6 is a schematic diagram illustrating transaction flow
in another example authentication system 600 that uses the 3DS 2
Protocol (or subsequent versions of the 3DS Protocol) for
authentication, and that performs RBA on behalf of ACS providers
that are unable to perform RBA. Unless otherwise indicated,
components of authentication system 600 are substantially similar
to those of authentication system 500 (shown in FIG. 5).
[0114] Instead of directory server 510, authentication system 600
includes an RBA-enabled directory server 610 communicatively
coupled to a RBA engine 612 (which may be collectively referred to
as an authentication platform 614). RBA-enabled directory server
610 and RBA engine 612 facilitate performing RBA behalf of ACS
providers, as described herein. RBA-enabled directory server 610
and RBA engine 612 may be operated, for example, by interchange
network 28 (shown in FIG. 1). In some embodiments, authentication
platform 614 is similar to RBA platform 34 (shown in FIG. 1) and
authentication server 112 (shown in FIG. 2).
[0115] As in authentication system 500, RBA-enabled directory
server 610 receives an AReq message from 3DS server 506. However,
instead of immediately forwarding the AReq message to ACS 512,
RBA-enabled directory server 610 transmits at least some of the
data in the AReq message (e.g., the authentication data) to RBA
engine 612.
[0116] In the example embodiment, RBA engine 612 analyzes the data
in the AReq message to generate RBA result data. For example, RBA
engine 612 may compare the data in the AReq message to one or more
long term variables ("LTV"). The one or more LTV may include
historical authentication data associated with the PAN at issue,
historical authorization data associated with the PAN, other
historical data associated with the PAN, etc. The LTV may be
associated with both card present and card not present historical
transactions. For example, the LTV may include cardholder shipping
address, cardholder billing address, cardholder email address,
cardholder phone number, merchant name, merchant category, merchant
location, and/or at least one environment-related variable (e.g.,
device details, browser details) including device ID, IP address,
device channel, etc. Further, the LTV may be stored in a database
accessible by RBA engine 612 and operated by interchange network
28. In some embodiments, the LTV data will be hashed prior to
storing to protect the security of this personally identifiable
information.
[0117] In addition, the data in the AReq message may also be
compared to other parameters. For example, to monitor consistency
and changes in behavior, the data may be compared to short term
(e.g., on the order of minutes, hours, or days) PAN velocities and
ratios, including velocities and ratios of PAN authorization and
authentication. This may include comparing to recent transaction
frequency, amount spent, declines, historical risk scores, etc.
Alternatively, the data in the AReq message may be analyzed using
any suitable techniques to generate RBA result data, as described
herein.
[0118] In the example embodiment, the RBA result data generated by
RBA engine 612 includes a risk score, a risk analysis, and at least
one reason code. The risk score is a score representing a
determined riskiness of the transaction, with lower scores
indicating lower risk and higher scores indicating higher risk. In
other words, the risk score represents a likelihood that the
suspect cardholder (e.g., the person attempting to perform a
transaction) is the legitimate cardholder having the privileges to
use the payment card to perform a payment transaction. For example,
the risk score may be represented by a number from 0-999 and/or by
a risk threshold category from 0-19. In some embodiments, risks
assessments that will be shared, such as through the authorization
field of one or more messages will be quantified on a scale of 0-9.
Those of skill in the art will appreciate that any suitable risk
score may be used.
[0119] The risk analysis is a description of a level of risk
corresponding to the risk score (e.g., low risk, medium risk, or
high risk). Further the reason codes include one or more factors
that influenced the risk score. RBA engine 612 transmits the RBA
result data to RBA-enabled directory server 610.
[0120] In some embodiments, the reason codes are generated based on
a plurality of reason code categories and associated anchors.
Specifically, different categories are established, and each
category is associated with a plurality of activatable anchors, as
described herein. Based on the analysis of the data in the AReq
message, RBA engine 612 may activate one or more anchors. The
reason codes are then generated based on which anchors (and how
many anchors) are activated. In some embodiments, the reason codes
are affected by rules and/or a combination of the rules and the
model.
[0121] For example, in one embodiment, three risk code categories
are established: cardholder, merchant, and environment. In this
example, the cardholder category is associated with five anchors
(shipping address, PAN, billing address, email, and phone), the
merchant category is associated with three anchors (merchant name,
merchant category, and merchant country), and the environment
category is associated with three anchors (device info, IP address,
and device channel). Those of skill in the art will appreciate that
additional and/or alternative anchors may be established.
[0122] Based on analysis of the data in the AReq message, RBA
engine 612 may activate at least one anchor. For example, for the
cardholder category, if RBA engine 612 determines that a shipping
address for the transaction has been used with the PAN in past
transactions and/or the shipping address is unchanged from prior
transaction, RBA engine 612 may activate the shipping address
anchor. Further, RBA engine 612 may activate the PAN anchor of the
cardholder category if the PAN has had successful authentications
in past transactions.
[0123] For the merchant category, one or more anchors may be
activated based fraud rates for the merchant, decline rates for the
merchant, and non-cleared transaction rates for the merchant.
Further, one or more anchors may be activated when RBA engine 612
determines the merchant category and merchant location for the
transaction are consistent with historical transactions for that
merchant.
[0124] For the environment category, the IP address anchor may be
activated if the IP address is known and is not on a list of "bad"
IP addresses. Further, the device anchor may be activated if the
device is known and is not on a list of "bad" devices, the device
has had successful authentications in past transactions, and/or the
device has scored well in past transactions.
[0125] The following are some additional examples of criteria for
activating anchors for the different categories. In one example,
the shipping address anchor is activated if the shipping address
has been used with the PAN in past transactions, the shipping
address is the same as the billing address on file, the shipping
address is not on a list of "bad" shipping addresses, and the
shipping address is unchanged from a prior transaction. In a second
example, the shipping address anchor, the billing address anchor,
and the PAN anchor (i.e., all anchors for the cardholder category)
are activated when the shipping address is consistent with previous
transactions, the billing address is consistent with previous
transactions, the PAN has historical positive association with the
cardholder, and the purchase amount, date, and time are consistent
with previous transactions. In a third example, anchors for both
the cardholder category and the merchant category are activated
when the contact information for the cardholder is consistent with
previous transactions, the cardholder is a trusted cardholder, the
merchant is a trusted merchant, and the PAN shows established
activity and authentication history at the merchant. Those of skill
in the art will appreciate that the anchors may be activated based
on any suitable conditions.
[0126] The reasons codes are generated based on the activated
anchors, and are loosely structured in a hierarchical order based
on connections between anchors in different categories. For
example, if at least one anchor in the cardholder category is
activated, a positive reason code (i.e., indicating relatively low
risk) is generated. If, instead, at least one anchor in the
cardholder category is activated and at least one anchor in the
merchant category is also activated, a stronger positive reason
code related to both categories is generated. Similarly, if at
least one anchor in the cardholder category is activated, at least
one anchor in the merchant category is activated, and at least one
anchor in the environment category is activated, an even stronger
positive reason code related to all three categories is
generated.
[0127] The following Table 3 lists of number of example reason
codes. However, those of skill in the art will appreciate that
additional and/or alternative reason codes may be utilized in
accordance with the embodiments described herein.
TABLE-US-00004 TABLE 3 Code Reason Code Name Description and
Comments A Risk Event - Suspicious Account Merchant or payment
network has Activity detected suspicious activity with cardholder's
account B Risk Event - Unknown Merchant or payment network has not
Device/Account Relationship established a relationship between the
device and account C Risk Event - Device or Profile The device used
for the transaction or Information associated with fraud the user's
profile has been associated event with a fraud event D Risk Event -
Recent High Risk The device used for the transaction or Change to
Device or Profile the user's profile has recently had a Information
high risk change E Risk Event - Recent change to Device The device
used for the transaction or or Profile Information the user's
profile has recently changed F Risk Event - PAN associated with
Merchant or payment network has fraud event detected fraud
associated with the PAN used for this transaction G New Account or
Insufficient Data This is a new account with the merchant (or new
cardholder details to payment network) or there is insufficient
data for this cardholder H Merchant/Acquirer: Merchant (fraud)
Payment network has determined that risk high (assessed by payment
the merchant is submitting transactions network) with a high rate
of fraud I Merchant/Acquirer: Merchant (fraud) Payment network has
determined that risk low (assessed by payment the merchant is
submitting transactions network) with a higher rate of fraud than
average J Environment: Good/Known IP Merchant or payment network is
familiar with the IP address where the transaction is happening and
has assessed that it is a good, trusted IP K Cardholder: Billing
address - prior Merchant or payment network has history established
established a positive association between the cardholder and this
billing address L Cardholder: Email address - prior Merchant or
payment network has history established established a positive
association between the cardholder and this email address. M
Cardholder: Phone number - prior Merchant or payment network has
history established established a positive association between the
cardholder and this phone number. N Cardholder: Shipping address -
prior Merchant or payment network has history established
established a positive association between the cardholder and this
shipping address. O Cardholder: Card number (PAN) Merchant or
payment network has behavior established high trust in established
high trust in the transaction the current transaction based on
historical PAN behavior P Environment: Device known Merchant or
payment network has seen the device used for the transaction
before, but this account might not be established on device Q
Environment: Account established on Merchant or payment network has
seen Device this account transaction on this device AND account has
been authenticated on the device R Environment: Session - Merchant
or payment network Trusted/normal/innocent session (no determines
quality of the session man in the middle attack/no bot, not
suspicious account activity) S More than one cardholder category
Merchant or payment network has anchor established established
multiple cardholder category anchors T More than one merchant
category Payment network has established anchor established
multiple merchant category anchors U More than one environment
category Merchant or payment network has anchor established
established multiple environment category anchors V Co-occurring:
established link Merchant or payment network has between cardholder
and merchant established linkages across cardholder and merchant
categories W Co-occurring: established link Merchant or payment
network has between cardholder and environment established linkages
across cardholder and environment categories X Co-occurring:
established link Payment network has established between merchant
and environment linkages across merchant and environment categories
Y All three categories established Payment network has established
linkages across cardholder, merchant, and environment categories Z
Most Trusted (Reserved for future Reserved for future use use)
[0128] After RBA engine 612 generates the RBA result data
(including the reason codes), RBA-enabled directory server 610
embeds the RBA result data into the AReq message to generate an
enhanced AReq message. For example, in some embodiments, the RBA
result data is appended to the AReq message as an extensible markup
language (XML) extension of the AReq message. For example, the
extension may have the following format:
TABLE-US-00005 "name": "ACS RBA", "id": "A000000004-acsRBA",
"criticalityIndicator": "true", "data": { "status":"success",
"score":"150", "decision":"low risk", "reasonCode1":"Y",
"reasonCode2":"J"}
where "score" is the risk score, "decision" is the risk analysis,
and "reasonCode1" and "reasonCode2" are the reason codes. In the
exemplary embodiment, the reason codes are transmitted as a single
letter each. In other embodiments, the reason codes may be
represented in different methods. In some embodiments, reasonCode2
is transmitted by the merchant to provide the merchant's assessment
of the transaction. Alternatively, the RBA result data may be
embedded into the AReq message to generate an enhanced AReq message
using any suitable process.
[0129] The enhanced AReq message is then transmitted from
RBA-enabled directory server 610 to ACS 512. ACS 512 then analyzes
the RBA result data in the enhanced AReq message to make an
authentication decision. That is, in the example embodiment, ACS
512 may determine to fully authenticate the transaction, deny
authentication for the transaction, or perform additional
authentication (e.g., by issuing a step-up challenge to the
cardholder) for the transaction, based on at least one of the risk
score, the risk analysis, and the reason codes. Accordingly, ACS
512 does not perform the RBA analysis, but is still able to
leverage the results of that analysis to make an authentication
decision (e.g., by using the results in their own fraud analysis
platform), generally resulting in more approvals with less fraud.
Thus, RBA-enabled directory server 610 and RBA engine 612 perform
the RBA analysis on behalf of ACS 512. In some embodiments, the ACS
512 receives authentication data from a plurality of sources.
[0130] In some embodiments, when the determined riskiness of the
transaction is low enough, instead of generating and transmitting
an enhanced AReq message to ACS 512, RBA-enabled directory server
610 fully authenticates the transaction itself. Specifically, when
the determined riskiness of the transaction is low enough,
RBA-enabled directory server 610 automatically generates an ARes
that indicates the transaction has been fully authenticated, and
transmits the ARes message to 3DS server 506. RBA-enabled directory
server 610 determines that the riskiness of the transaction is low
by comparing at least one of the risk score and the risk analysis
to a predetermined threshold. The predetermined threshold may be
specified, for example, by ACS 512. Accordingly ACS 512 is able to
control which transactions will be fully authenticated without all
transactions being forwarded to ACS 512.
[0131] Bypassing ACS 512 for low risk transactions reduces the
overall message volume on the payment network. This in turn frees
up network resources, improving transmission speed and overall
capability of the payment network. Furthermore, in some
embodiments, RBA-enabled directory server 610 determines if ACS 512
is available. In some situations, ACS 512 may be off-line or
unavailable. If the ACS 512 is available, then the RBA-enabled
directory server 610 may route the enhanced AReq message including
the RBA result data to the ACS 512. If the ACS 512 is not
available, RBA-enabled directory server 610 may perform the
authentication processing.
[0132] FIG. 7 is a flow diagram of an example method 700 for
authenticating an online user on behalf of an access control server
(ACS). Method 700 may be implemented, for example, using
authentication platform 614 (shown in FIG. 6). Method 700 includes
receiving 702 an authentication request message, the authentication
request message includes authentication data. Method 700 further
includes extracting 704 the authentication data from the
authentication request message. Method 700 further includes 706
generating, based at least in part on the extracted authentication
data, RBA result data including a risk score, a risk analysis, and
at least one reason code. In addition, method 700 includes
embedding 708 the RBA result data into the authentication request
message to generate an enhanced authentication request message.
Further, method 700 includes transmitting 710 the enhanced
authentication request message to the ACS to enable the ACS to make
an authentication decision based on the RBA result data.
[0133] FIG. 8 is a flow diagram of another example method 800 for
authenticating an online user. Method 800 may be implemented, for
example, using authentication platform 614 (shown in FIG. 6).
[0134] In the example embodiment, authentication platform 614
receives 802 an authentication request message including
authentication data, as described herein. Authentication platform
614 performs 804 RBA to generate RBA result data including a risk
score, a risk analysis, and at least one reason code. The risk
score is a score representing a determined riskiness of the
transaction, with lower scores indicating lower risk and higher
scores indicating higher risk. In other words, the risk score
represents a likelihood that the suspect cardholder (e.g., the
person attempting to perform a transaction) is the legitimate
cardholder having the privileges to use the payment card to perform
a payment transaction. For example, the risk score may be
represented by a number from 0-999 and/or by a risk threshold
category from 0-19. In some embodiments, risks assessments that
will be shared, such as through the authorization field of one or
more messages will be quantified on a scale of 0-9. The risk
analysis is a description of a risk level corresponding to the risk
score (e.g., low risk, medium risk, or high risk). The reason codes
include one or more factors that influenced the risk score.
[0135] In the example embodiment, authentication platform 614
compares the RBA result data to a stored authentication profile.
The authentication profile contains a plurality of rules for the
processing of authentication requests. In some embodiments, the
authentication profile is provided by the issuer computing device
514 (shown in FIG. 5). Examples of the rules include, but are not
limited to, how to proceed when the ACS 512 (shown in FIG. 5) is
unavailable, information to include in the RBA, risk level
thresholds for the risk score and risk levels, decision making risk
thresholds, and specialized rules (such as all cross-border
transactions are to be submitted to the ACS 512). The
authentication profile is stored at the RBA platform, and can be
accessed whenever a risk score is determined.
[0136] In the example embodiment, authentication platform 614
compares the RBA result data to the authentication profile to
determine the risk level associated with the transaction associated
with the authentication request. In some embodiments,
authentication platform 614 compares the risk score to one or more
thresholds in the authentication profile to determine the risk
level associated with the transaction. In other embodiments,
authentication platform 614 compares the risk analysis, the reason
codes, and/or any other combination of data from the RBA result
data and potentially some or all of the authentication data to the
authentication profile to determine the risk level associated with
this transaction. For example, a risk score of 900 or less may be
considered low risk, a risk score between 900 and 980 may be
considered medium risk, and a risk score above 980 may be
considered high risk. Those skilled in the art will appreciate that
any suitable risk score thresholds and any number of risk levels
may be used.
[0137] In the example embodiment, authentication platform 614
determines 806 if the risk level is high risk. For example,
authentication platform 614 may determine 806 that the transaction
is clearly fraudulent. In which case, authentication platform 614
fails the authentication and denies 808 the transaction. In the
example embodiment, authentication platform 614 may deny 808 the
transaction. Authentication platform 614 transmits an
authentication response (ARes) message including the denial to 3DS
server 506 (shown in FIG. 5). The 3DS server 506 may transmit the
Ares message including the denial to the merchant, where the
merchant determines whether or not to proceed with the
authorization process. In these embodiments, where the merchant
begins the authorization process after having received a denial,
the transaction is considered to be merchant only authentication,
where the merchant assumes the risk for the transaction.
[0138] When authentication platform 614 determines the transaction
is clearly fraudulent, authentication platform 614 denies the
transaction without sending on authentication data (e.g., to the
ACS and/or issuer). Specifically, authentication platform 614 fails
the authentication and communicates the failure to the
authentication requestor in the ARes message. Based on this
failure, the merchant should not then submit the transaction for
authorization, thus terminating the transaction. Accordingly,
because the transaction is denied during authentication (and prior
to authorization), no authorization messages are sent over the
payment processing network. This protects the security of the
payment processing network, because the payment processing network
is never exposed to authorization data associated with the
fraudulent transaction. Further, authentication platform 614 may
notify the issuer and/or merchant that the transaction was clearly
fraudulent, enabling the issuer and/or merchant to take appropriate
action (e.g., flagging the associated account number and/or
cardholder).
[0139] Authentication platform 614 determines 810 if the
transaction is medium risk or low risk. If the transaction is low
risk, authentication platform 614 may approve 814 the transaction
and transmit an authentication response (ARes) message including
the approval to 3DS server 506, where at least one of the 3DS
server 506 and the merchant may initiate the authorization process.
If the transaction is medium risk, authentication platform 614 may
issue 812 a step-up challenge to the cardholder 22 (shown in FIG.
1). Based on the results of the step-up challenge, authentication
platform 614 may approve or deny the transaction. In some
embodiments, if the transaction is medium risk, authentication
platform 614 transmits the RBA result data to ACS 512, so that the
ACS 512 will perform the step-up challenge. In other embodiments,
authentication platform 614 may take different steps at different
risk levels and have additional or fewer risk levels to analyze
based on the authentication profile.
[0140] FIG. 9 is a flow diagram of another example method 900 for
authenticating an online user. Method 900 may be implemented, for
example, using authentication platform 614 (shown in FIG. 6).
Method 900 includes storing 902 an authentication profile. The
authentication profile contains a plurality of rules for the
processing of authentication requests. The method 900 also includes
receiving 904 an authentication request message, the authentication
request message includes authentication data. Method 900 further
includes extracting 906 the authentication data from the
authentication request message. Method 900 further includes
generating 908, based at least in part on the extracted
authentication data, RBA result data including a risk score, a risk
analysis, and at least one reason code. In addition, method 900
includes routing 910 the RBA result data based on the
authentication profile and the RBA result data.
[0141] In some embodiments, the authentication platform 614
transmits the RBA result data to a source of the authentication
request message, such as the 3DS server 506 (shown in FIG. 5). For
example, in some embodiments, a merchant operating the 3DS server
506 may request and receive the RBA result data, including a risk
score, a risk analysis, and at least one reason code as described
herein. The merchant may use the RBA result data to update the
merchant's own risk models, and may also compare the RBA result
data to risk analysis results generated independently by the
merchant to determine whether the RBA result data is generally
consistent with the merchant-generated risk analysis results.
[0142] In some embodiments, the authentication request message is
associated with an online payment card transaction. The
authentication profile is associated with an issuer bank 30 (shown
in FIG. 1). And the source of the authentication request message is
the issuer computing device 514 (shown in FIG. 5). Accordingly, in
some embodiments, the authentication platform 614 transmits the RBA
result data directly to the issuer computing device 514, and
handles authentication with the issuer computing device 514. For
example, the issuer bank 30 may enroll a range of card numbers with
the authentication platform 614, and request that the
authentication platform 614 work directly with the issuer computing
device 514 for authentication of transactions involving card
numbers in the enrolled range.
[0143] In some embodiments, the authentication platform 614
determines whether an access control server (ACS) 512 (shown in
FIG. 5) is available. If the ACS 512 is available, the
authentication platform 614 embeds the RBA result data into the
authentication request message to generate an enhanced
authentication request message. The authentication platform 614
transmits the enhanced authentication request message to the ACS
512 to enable the ACS 512 to make an authentication decision based
on the RBA result data. If the ACS 512 is unavailable, the
authentication platform 614 generates an authentication decision
based on the RBA result data and the authentication profile.
[0144] In some further embodiments, the authentication platform 614
determines a risk level based on the RBA data and the
authentication profile. In some of these embodiments, the risk
level includes at least a low risk, a medium risk and a high risk
for the transaction associate with the authentication request. In
these embodiments, the authentication platform 614 transmits an
authentication approval message to the 3DS server 506, if the risk
level is low.
[0145] If the risk medium, the authentication platform 614
transmits a step-up challenge to the online user 22 (shown in FIG.
1) if the risk level is medium. The authentication platform 614
receives a response to the step-up challenge from the online user
22. The authentication platform 614 determines an authentication
decision based on the response to the step-up challenge and the RBA
result data. In some other embodiments, if the risk is medium, the
authentication platform 614 transmits the RBA result data to the
ACS 512 if the risk level is medium. The ACS 512 performs the
step-up challenge with the online user 22.
[0146] If the risk is high, the authentication platform 614
transmits an authentication denied message to the 3DS server
506.
[0147] FIG. 10 is a flow diagram of a further example method 1000
for authenticating an online user on behalf of an access control
server (ACS) 512 (shown in FIG. 5). Method 1000 may be implemented,
for example, using authentication platform 614 (shown in FIG. 6).
Method 1000 includes receiving 1002 an authentication request
message for a transaction. The authentication request message
includes authentication data. The method 1000 also includes
extracting 1004 the authentication data from the authentication
request message. The method 1000 further includes determining 1006
if the ACS 512 is available to process the transaction. If the ACS
512 is unavailable, the method includes generating 1008, based at
least in part on the extracted authentication data, risk-based
authentication (RBA) result data including a risk score and at
least one reason code that indicates at least one factor that
influenced the generated risk score. If the ACS 512 is unavailable,
the method also includes transmitting 1010 an authentication
response message based on the RBA result data. In some embodiments,
the authentication platform 614 generates an authentication
decision based on the RBA result data and embeds the authentication
decision in the authentication response message.
[0148] In the example embodiment, transactions are categorized
"merchant only" or "fully authenticated." "Fully authenticated"
transactions are generally considered to be low risk transactions
that have been authenticated. "Merchant only" transactions are more
risky transactions. In some embodiments, "merchant only"
transactions have been authenticated. In the example embodiment,
one or more indicators in the authentication response indicate
whether a transaction is "merchant only" or "fully authenticated."
One or more indicators may also indicate whether or not
authentication was attempted on the transaction. This information
is used by the merchant to determine whether or not to begin the
authorization process for the transaction. In some embodiments,
this information is also stored in the database 120 (shown in FIG.
2) and is referred to by at least one of the interchange network 28
and the issuer bank 30 during the authorization process 20 (all
shown in FIG. 1).
[0149] In the example embodiment, the authentication platform 614
performs the authentication process on the transaction, including
RBA. This analysis is based on a machine learning model where, over
time, the authentication platform 614 is capable of improving its
ability to determine the risk level associated with transactions.
The authentication platform 614 analyzes transactions that are
authenticated by the ACS 512 and compares these transactions with
historical data to generate a risk model for each issuer bank 30.
By comparing the data points in each transaction, the risk model
will indicate the amount of risk associated with each transaction
based on the authentication data in the corresponding
authentication requests. This allows the authentication platform
614 to analyze transactions when the ACS 512 is unavailable and
perform authentication on these transactions to provide a response
to the authentication request. Accordingly, the authentication
platform 614 may determine that a received authorization request is
substantially similar to a previous transaction that the ACS 512
scored at low risk. Thus allowing the authentication platform 614
to determine that the received transaction is low risk with a
degree of certainty.
[0150] In some embodiments, the authentication platform 614
determines whether or not the ACS 512 available by transmitting the
authentication request message to the ACS 512. In these
embodiments, the authentication platform 614 waits a predetermined
period of time for a response from the ACS 512. The authentication
platform 614 determines that the ACS 512 is unavailable if no
response is received from the ACS 512 after the predetermined
period of time. Alternatively, the authentication platform 614 may
receive a response from the ACS 512 that indicates that the ACS 512
is unable to perform authentication. The response from the ACS 512
may indicate that the online user is not enrolled with the ACS 512,
that the ACS 512 is currently unavailable, or that the ACS 512 was
unable to authenticate the online user. This indication may be
contained in the response message from the ACS 512. In other
embodiments, the authentication platform 614 may transmit periodic
status check messages to the ACS 512 to determine whether or not
the ACS 512 is available.
[0151] In some embodiments, the authentication platform 614
determines that the online user is not associated with the ACS 512
based on the extracted authentication data. In these embodiments,
the issuer associated with the online user has not registered with
an ACS 512. In these embodiments, the authentication platform 614
generates an authentication decision based on the RBA result
data.
[0152] In some further embodiments, the authentication platform 614
determines whether the authentication request message complies with
the 3DS 2 Protocol or subsequent versions of the 3DS Protocol. If
the authentication request message does not comply with the
appropriate 3DS Protocols, the authentication platform 614 bypasses
determining if the ACS 512 is available. In this situation, the
authentication platform 614 transmits an authentication response
message indicating that the transaction is considered merchant only
and that no authentication was attempted.
[0153] In some embodiments, the authentication platform 614
determines a risk level based on the RBA result data. If the risk
level is low, the authentication platform 614 embeds an indicator
in the authentication response message indicating that the
transaction is "fully authenticated." If the risk level is not low,
the authentication platform 614 embeds one or more indicators in
the authentication response message indicating that the transaction
is a merchant only transaction and that authentication was
attempted.
[0154] FIGS. 11A and 11B are swim-lane diagrams illustrating
additional example embodiments involving conditional SCA evaluation
on transactions associated with a regulated market. FIG. 11A is
directed to transactions that are allowed to avoid
regulator-imposed SCA step-up challenges when the transactions are
determined to be of sufficiently low risk and low value. FIG. 11B
is directed to transactions that are forced into SCA step-up
challenges when the transactions are more risky or when the
transactions are of higher value. In such scenarios, any of the
above-described systems and methods involving the RBA-enabled
directory server (or just "directory server") 610 and RBA engine
612 may be employed in conjunction with conditional SCA, subject to
the restrictions imposed by regulators as described herein.
[0155] Referring now to FIG. 11A, in this example embodiment, at
step 1110, the cardholder 22 initiates an online transaction with a
merchant, represented here by 3DS server 506, via their computing
device, represented here by 3DS client 502. 3DS server 506
generates and transmits an AReq message 1102 to directory server
610 at step 1112 and extracts transaction data from AReq message
(e.g., as described above with respect to FIG. 6). AReq message
1102 includes a transaction value for the transaction, as well as
other authentication data associated with the transaction (e.g., as
a 3DS AReq message). Directory server 610 receives AReq message
1102 and determines that the transaction involves a market
regulated by a regulatory entity, such as a central bank of a
particular country associated with the transaction (e.g., based on
the identity or location of cardholder 22, merchant 24, merchant
bank 26, or issuer bank 30).
[0156] Transactions in some regulated markets may be subject to
forced SCA for all transactions. In the example embodiment, the
regulated market for this example transaction has opted into
conditional SCA as described herein. In such markets, regulators
may generally mandate SCA on transactions, but may allow
transactions to be authenticated without SCA in particular
circumstances. As such, directory server 610 identifies a
transaction limit and a risk threshold for conditional SCA of that
particular regulated market. The transaction limit represents a
threshold transaction value below which SCA may be avoided if the
risk threshold is also satisfied. In the embodiments described
herein, the transaction limit may be, for example, a monetary value
for a particular transaction (e.g., 2000 rupees, 30 Euro, etc.), a
number of transactions (e.g., 5 frictionless transactions), or a
cumulative monetary value (e.g., 100 Euro). Accordingly, the
transaction limit may be defined by parameters other than a
monetary value of the transaction. Those of skill in the art will
appreciate that any suitable type of transaction limit may be
established.
[0157] The risk threshold represents a level of risk of fraud
associated with the transaction (e.g., as determined, or "scored,"
by RBA engine 612). In other words, and for example, if the risk
level of the transaction is "low" (e.g., below a risk score
threshold) and the transaction is a "low-value" transaction (e.g.,
below the transaction threshold value), then SCA may not be
mandated by the regulated entity. If the transaction value is not a
low-value transaction (e.g., at or above the transaction threshold
value) or if the transaction is not a low-risk transaction (e.g.,
at or above a risk score threshold), then SCA may be mandated by
the regulated entity.
[0158] Directory server 610 compares the transaction value to the
transaction limit set by the regulatory entity and, in this
example, determines that the transaction value is less than the
transaction limit (e.g., the transaction is a "low-value"
transaction). As such, directory server 610 engages RBA engine 612
at step 1114 to evaluate risk associated with AReq. RBA engine 612
evaluates risk associated with the transaction using the
authentication data and other transaction data associated with
AReq, as described above. RBA engine 612 generates risk-based
authentication result data that includes a risk score for the
transaction.
[0159] In this example, RBA engine 612 compares the risk score
generated for this transaction to the risk threshold identified for
this regulated market and determines that the risk of fraud in this
transaction is below the risk threshold. In some embodiments, the
risk score and the risk threshold may be integer values that may be
compared to determine whether the risk score is more or less than
the risk threshold. In other embodiments, the risk threshold may be
a category of a tiered set of categories (e.g., "low", "medium",
"high") and the risk score may be of that same tiered set of
categories, or the risk score may be a value that is mapped into
that tiered set of categories (e.g., with regulator-, issuer-, or
system-defined ranges for each category). For example, RBA engine
612 may allow the regulators for this market to define the "low
risk" category as being any transaction score below 400 (e.g., as
evaluated under 3DS 2 by RBA engine 612).
[0160] Continuing this example, RBA engine 612 has determined, at
step 1104, that the transaction is both "low" and "below." In other
words, the transaction is both a low-value transaction as well as
below the regulator's transaction threshold. As such, as far as the
regulator is concerned, the transaction is not mandated to have SCA
performed. However, some issuers may have more stringent
requirements for SCA step-up, or may have other reasons for
rejecting authentication regardless of SCA step-up considerations.
For example, some issuers may reject any CNP transaction evaluating
to a "high" risk. For ease of description, such flow and rejections
are not expressly illustrated in FIGS. 11A and 11B. Rather, FIGS.
11A and 11B focus on scenarios involving when SCA is mandated or
allowed to be avoided.
[0161] In some scenarios, the authentication platform (e.g.,
directory server 610 and RBA engine 612) may be entrusted to
perform authentication processing on behalf of issuer 514. In other
scenarios, authentication may be performed by ACS 512. As such, at
test 1116, if the authentication platform is acting on behalf of
issuer 514 for authentication, then RBA engine 612 generates an
ARes message 1106 approving the transaction at step 1118 (presuming
no other reason for authentication rejection) and transmits ARes
1106 to 3DS server 506 at step 1120 without having performed SCA
step-up authentication on consumer 22.
[0162] If, at test 1116, the authentication platform does not
perform authentication on behalf of issuer 514 (e.g., issuer 514
has ACS 512 perform authentication services), then RBA engine 612
transmits an enhanced AReq message 1108 to ACS 512 at step 1122.
Enhanced AReq may include, in addition to the additional RBA data
described above associated with 3DS 2, a data field indicating that
SCA step-up is not mandated by the involved market(s) for this
transaction. However, issuer 514 or ACS 512 may otherwise determine
to perform SCA on the transaction (e.g., if preferred by the issuer
for certain types of transactions or other considerations). If, at
test 1130, ACS 512 does not prompt SCA step-up, then ACS 512
returns an ARes message 1132 to the authentication platform at step
1134 approving authentication of the transaction.
[0163] If, at test 1130, ACS 512 determines to prompt SCA step-up,
then ACS 512 prompts step-up 1138 via 3DS server 506 (or 3DS client
502) at step 1136. Consumer 22 provides step-up input 1142 back to
3DS server 506 (or directly to ACS 512) and, upon successful
step-up, ACS 512 transmits the ARes message 1132 to the
authentication service at step 1146.
[0164] Referring now to FIG. 11B, in this example, the
authentication platform determines that the transaction does not
meet the requirements to avoid SCA step-up and, as such, SCA
step-up is mandated. In the example embodiment, RBA engine 612
determines, at step 1150, that either the transaction value is
above the transaction limit set by the regulatory entity, or that
the transaction risk does not satisfy the risk threshold set by the
regulatory entity, or both. If, at test 1152, the authentication
platform is acting on behalf of issuer 514, and presuming no other
reason for denying authentication of the transaction, RBA engine
612 prompts step-up 1156 of consumer 22 at step 1154. Consumer 22
responds with step-up input 1142 at step 1140, either directly with
directory server 610 or via 3DS server 506 at step 1158 and, upon
successful step-up challenge, 3DS server 506 transmits ARes message
1106 to 3DS server 506 approving authentication of the
transaction.
[0165] If, at test 1152, ACS 512 is acting on behalf of issuer 514,
RBA engine 612 transmits, at step 1154, the enhanced AReq 1108
(represented here by 1162) along with an indication to force SCA
step-up challenge of consumer 22 for this transaction. Enhanced
AReq may include, in addition to the additional RBA data described
above associated with 3DS 2, a data field mandating ACS 512 to
perform SCA step-up for the transaction (e.g., if the transaction
is otherwise deemed to be approved for authentication by ACS 512).
In other words, AReq 1108 serves to inform ACS 512 that the
transaction may not be authenticated without SCA. Presuming no
other reason to reject authentication of the transaction, ACS 512
identifies that the transaction is subject to a mandated SCA
step-up and prompts step-up 1138 in steps 1136, 1140, 1144, and
transmits ARes 1132 approving the transaction in steps 1146 and
1120, as described above.
[0166] In some embodiments, the authentication platform provides a
graphical user interface (GUI) dashboard (not shown) for use by the
regulators. The GUI may, for example, allow the regulators to view
and evaluate fraud data associated with their market. For example,
in one embodiment, the GUI dashboard may be configured to display
historical fraud data indicating a level of fraud present in
transactions not mandated to be authenticated with SCA by RBA
engine 612 when satisfying the risk threshold and transaction limit
set by the regulatory entity (e.g., a percentage of "frictionless
transactions" within RBA, perhaps including approval rates or basis
points of fraud). In one embodiment, the GUI dashboard may be
configured to display historical fraud data indicating a level of
fraud present in transactions mandated to be authenticated with SCA
by the RBA engine 612 when not satisfying one or more of the risk
threshold or transaction limit (e.g., percentage of transactions
stepped-up within RBA, perhaps with the type of step-up, approval
rates, basis points of fraud). Such data may include an electronic
gross dollar value (eGDV), an eTransaction count, or growth over
time for such metrics. Such data may also be presented by channel.
For example, such data may be limited to mobile device
transactions, browser-based transactions, telephone transactions,
and mail transactions. As such, the GUI may allow the regulators to
determine how their current settings are impacting fraud in these
types of transactions.
[0167] In some embodiments, the GUI allows the regulators to adjust
conditional SCA settings associated with their market. For example,
the GUI may allow the regulators to alter the risk threshold
required to avoid SCA, or to alter the transaction limit for
transactions that can avoid SCA. In some embodiments, the GUI
provides simulation analysis of prospective changes to the
conditional SCA settings. For example, using historical data, the
GUI may provide a fraud impact analysis to a proposed higher risk
threshold, or to a proposed higher transaction limit, perhaps
estimating a predicted level of fraud at the proposed settings. As
such, the GUI may allow the regulators to determine potential
impacts or potential results based on prospective changes.
[0168] FIG. 12 is a flow diagram of an advanced authentication
process 1200 for increasing approvals, reducing fraud, and
improving consumer experience. Authentication process 1200 may be
implemented, for example, using the systems and methods described
herein. As shown in FIG. 12, authentication data 1202 is
transmitted to an authentication platform 1206 (such as
authentication platform 614) through a smart interface 1204. As
described above, as compared to previous authentication methods
(e.g., 3DS 1.0), authentication data 1202 under the 3DS 2 Protocol
(and subsequent versions of the 3DS Protocol) includes
approximately ten times the amount of transaction data to be
gathered, analyzed, and utilized to prevent fraud. Using
authentication data 1202, authentication platform 1206 performs
smart authentication 1208 (as described herein) to generate RBA
results data. Decision intelligence (DI) 1210 uses other sources of
data (i.e., a separate model) to influence authorization decisions.
In some embodiments, the RBA results data may be incorporated into
DI 1210. These assessments enable an interested party 1212 (e.g.,
the ACS, the merchant, and/or the issuer) to complete
authentication (and authentication) of the transaction.
[0169] Authentication process 1200 enables authenticating an online
user as a legitimate user of a payment account without having to
ask additional questions of the user (e.g., as part of a step-up
challenge) or having to request additional inputs from the user.
Thus, authentication process 1200 assesses a risk of fraud without
creating any additional friction for the user that may cause the
user to terminate a transaction.
[0170] A processor or a processing element may employ artificial
intelligence and/or be trained using supervised or unsupervised
machine learning, and the machine learning program may employ a
neural network, which may be a convolutional neural network, a deep
learning neural network, or a combined learning module or program
that learns in two or more fields or areas of interest. Machine
learning may involve identifying and recognizing patterns in
existing data in order to facilitate making predictions for
subsequent data. Models may be created based upon example inputs in
order to make valid and reliable predictions for novel inputs.
[0171] Additionally or alternatively, the machine learning programs
may be trained by inputting sample data sets or certain data into
the programs, such as image data, text data, report data, and/or
numerical analysis. The machine learning programs may utilize deep
learning algorithms that may be primarily focused on pattern
recognition, and may be trained after processing multiple examples.
The machine learning programs may include Bayesian program learning
(BPL), voice recognition and synthesis, image or object
recognition, optical character recognition, and/or natural language
processing--either individually or in combination. The machine
learning programs may also include natural language processing,
semantic analysis, automatic reasoning, and/or machine
learning.
[0172] In superv
References