MasterCard SecureCode

Issuer Implementation Guide

2 December 2011
Notices
Proprietary Rights The information contained in this document is proprietary and confidential
to MasterCard International Incorporated, one or more of its affiliated entities
(collectively “MasterCard”), or both.
This material may not be duplicated, published, or disclosed, in whole or in
part, without the prior written permission of MasterCard.

Trademarks Trademark notices and symbols used in this document reflect the registration
status of MasterCard trademarks in the United States. Please consult with
the Customer Operations Services team or the MasterCard Law Department
for the registration status of particular product, program, or service names
outside the United States.
All third-party product and service names are trademarks or registered
trademarks of their respective owners.

Billing For printed documents, MasterCard will bill principal members. Please
refer to the appropriate MasterCard Consolidated Billing System (MCBS)
document for billing-related information.

Information Available MasterCard provides details about the standards used for this
Online document—including times expressed, language use, and contact
information—on the Member Publications Support page available on
MasterCard OnLine®. Go to Member Publications Support for centralized
information.

Translation A translation of any MasterCard manual, bulletin, release, or other

MasterCard document into a language other than English is intended solely
as a convenience to MasterCard members and other customers. MasterCard
provides any translated document to its members and other customers “AS
IS” and makes no representations or warranties of any kind with respect
to the translated document, including, but not limited to, its accuracy or
reliability. In no event shall MasterCard be liable for any damages resulting
from members’ and other customers’ reliance on any translated document.
The English version of any MasterCard document will take precedence over
any translated version in any legal proceeding.

Publication Code SNC

©2005–2011 MasterCard. Proprietary. All rights reserved.

2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
Table of Contents
Chapter 1 Overview ........................................................................................ 1-i
MasterCard and E-commerce ................................................................................................... 1-1
Maestro and E-commerce ........................................................................................................ 1-1
MasterCard Debit ..................................................................................................................... 1-2
MasterCard SecureCode Program ............................................................................................. 1-2
Typical Payment Transaction Participants................................................................................ 1-3
Cardholder ......................................................................................................................... 1-4
Issuer ................................................................................................................................. 1-4
Merchant............................................................................................................................ 1-4
Acquirer ............................................................................................................................. 1-4
MasterCard SecureCode Program Platform............................................................................... 1-5
What is UCAF and its Structure? ....................................................................................... 1-5
What is an AAV?................................................................................................................. 1-9
What is a Merchant Plug-In? .............................................................................................. 1-9
Rules to Support UCAF Liability Shift ...................................................................................... 1-9
Global Liability Shift Program .......................................................................................... 1-10
Merchant Only Liability Shift Program ............................................................................. 1-10
Liability Shift Rule Summary ............................................................................................ 1-11
UCAF Compliance Requirements........................................................................................... 1-13
Authorization Requirements............................................................................................. 1-13
Debit/Single Message System Requirements.................................................................... 1-15
Clearing Requirements..................................................................................................... 1-15
Enrollment Requirements....................................................................................................... 1-15
Maintenance Requirements.............................................................................................. 1-16
Participation Responsibilities ................................................................................................. 1-16
Responsibilities for all Members ..................................................................................... 1-16
Issuer Responsibilities...................................................................................................... 1-17
MasterCard SecureCode Compliance and Functional Testing ................................................ 1-18
MasterCard SecureCode Program Enrollment Procedure ....................................................... 1-18
MasterCard Support ............................................................................................................... 1-19
Project Management Support........................................................................................... 1-19
Regional MasterCard Office Support................................................................................ 1-19
Additional References ...................................................................................................... 1-19

Chapter 2 3-D Secure Solution Overview ...................................................... 2-i

Overview ................................................................................................................................. 2-1
Components............................................................................................................................. 2-1

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 i
Table of Contents

Issuer Domain.................................................................................................................... 2-1

Acquirer Domain ............................................................................................................... 2-2
Interoperability Domain..................................................................................................... 2-3
Messages.................................................................................................................................. 2-4
Card Range Request/Response .......................................................................................... 2-4
Verification Request/Response........................................................................................... 2-4
Payer Authentication Request/Response............................................................................ 2-4
Payer Authentication Transaction Request/Response ........................................................ 2-5
Cardholder Enrollment Process................................................................................................ 2-5
Enrollment—Static Password ............................................................................................. 2-5
Cardholder Authentication ..................................................................................................... 2-15
Sample Cardholder Authentication Process ..................................................................... 2-15

Chapter 3 Cardholders .................................................................................... 3-i

Overview ................................................................................................................................. 3-1
Infrastructure ........................................................................................................................... 3-1
Availability of Secure Browser ........................................................................................... 3-1
Customization .......................................................................................................................... 3-1
Operational.............................................................................................................................. 3-1
Cardholder Registration ..................................................................................................... 3-1
Use of Pop-Up Blocking Software ..................................................................................... 3-2
Accountholder Authentication Value Processing...................................................................... 3-2
Global Infrastructure Testing Requirements............................................................................. 3-2

Chapter 4 Customer Interface Requirements ................................................ 4-i

Purchase Authentication Page.................................................................................................. 4-1
General Program Requirements ......................................................................................... 4-1
Cardholder Standard Enrollment.............................................................................................. 4-3
Overall Registration Process .............................................................................................. 4-3
Welcome/Registration Landing Page.................................................................................. 4-5
Congratulations/Successful Registration Page .................................................................... 4-5
Communication.................................................................................................................. 4-5
Activation During Shopping Enrollment .................................................................................. 4-6
Benefits.............................................................................................................................. 4-7
General Requirements ....................................................................................................... 4-7
Cardholder Termination of ADS ........................................................................................ 4-9
Issuer-Mandated ADS Enrollment Requirements ............................................................... 4-9
Required Access Control Processing ........................................................................................ 4-9
Required Access Control Server Processing ........................................................................... 4-11

©2005–2011 MasterCard. Proprietary. All rights reserved.

ii 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 Table of Contents

Best Practices ......................................................................................................................... 4-12

Program Awareness ......................................................................................................... 4-12
Communication................................................................................................................ 4-12
Direct Enrollment Screens................................................................................................ 4-12
ADS Screens..................................................................................................................... 4-13

Chapter 5 Issuers ............................................................................................. 5-i

Overview ................................................................................................................................. 5-1
Infrastructure .......................................................................................................................... 5-1
Establishment of SecureCode Operating Environment....................................................... 5-1
Digital Signature Key Management.................................................................................... 5-2
Authorization System Message Enhancements................................................................... 5-3
Maestro Considerations...................................................................................................... 5-3
Customization .......................................................................................................................... 5-4
Authentication Window Contents ...................................................................................... 5-4
Program Identifier Usage Guidelines ................................................................................. 5-5
Establishment of Cardholder Enrollment Process .............................................................. 5-5
Operational.............................................................................................................................. 5-6
MasterCard SecureCode Directory Server Maintenance...................................................... 5-6
SSL and Digital Signing Certificates.................................................................................... 5-6
Customer Service ............................................................................................................... 5-6
Authentication History Server ........................................................................................... 5-7
Accountholder Authentication Value (AAV) Processing .......................................................... 5-7
SPA AAV Algorithm ............................................................................................................ 5-7
Electronic Commerce Indicator.......................................................................................... 5-7
AAV Validation and the AAV Validation Service ................................................................. 5-8
Global Infrastructure Testing Requirements............................................................................. 5-8
MasterCard SecureCode Toolkit ............................................................................................... 5-9
SecureCode 360 Webinar Series ............................................................................................... 5-9
MasterCard SecureCode Hosted ACS Service ........................................................................... 5-9

Chapter 6 Component Certificate Requirements .......................................... 6-i

Overview ................................................................................................................................. 6-1
Functional Certificate Authority Hierarchy............................................................................... 6-1
Public Zone ....................................................................................................................... 6-2
Trusted Zone ..................................................................................................................... 6-2
Operational Certificate Authority Hierarchy............................................................................. 6-3
Certificates ......................................................................................................................... 6-4
Requesting Certificates....................................................................................................... 6-6

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 iii
Table of Contents

Chapter 7 Issuer Authentication Options ...................................................... 7-i

Background ............................................................................................................................. 7-1
Static Password ........................................................................................................................ 7-1
Random Static .......................................................................................................................... 7-2
SMS .......................................................................................................................................... 7-2
Mobile Application .................................................................................................................. 7-4
CAP.......................................................................................................................................... 7-4
Display Card ............................................................................................................................ 7-5
Other Authentication Options.................................................................................................. 7-6
Virtual Card Numbers ........................................................................................................ 7-7
Risk Based Authentication ....................................................................................................... 7-7

Appendix A SecureCode SPA Algorithm Specifications ...............................A-i

Accountholder Authentication Value Layout............................................................................A-1
Base64 Encoding .....................................................................................................................A-1
Introduction .......................................................................................................................A-1
Examples ...........................................................................................................................A-1

Appendix B Contact Information ................................................................... B-i

Contact Information .................................................................................................................B-1
MasterCard SecureCode Online Resources .......................................................................B-1

Appendix C Marketing Best Practices for Issuers.......................................... C-i

Consumer Positioning..............................................................................................................C-1
Key Consumer Messages ...................................................................................................C-1
Communication Strategy ..........................................................................................................C-2
Online Stategy .........................................................................................................................C-2
Issuer’s Site ........................................................................................................................C-2
MasterCard Web Support ...................................................................................................C-2
Banner Ads ........................................................................................................................C-3
Acquisition Stategy.............................................................................................................C-3
Confirmation of Enrollment E-mail ....................................................................................C-3
Usage/New Merchant E-mail .............................................................................................C-4
Mail Vehicles ......................................................................................................................C-4
Available Marketing Materials ..................................................................................................C-5
MasterCard SecureCode Issuer Best Practice Guide ...........................................................C-5

Appendix D Maestro Considerations.............................................................D-i

Account in Good Standing...................................................................................................... D-1

©2005–2011 MasterCard. Proprietary. All rights reserved.

iv 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 Table of Contents

Appendix E MasterCard Advance Registration Program ............................. E-i

MasterCard Advance Registration Program .............................................................................. E-1
Participation Requirements for Merchants ......................................................................... E-1
MARP Merchant Use of MasterCard SecureCode................................................................ E-2
Acquirer Impact ................................................................................................................. E-3
Issuer Impact ..................................................................................................................... E-3

Appendix F Issuer Implementation Process................................................... F-i

Overview ................................................................................................................................. F-1
Business User Requirements .................................................................................................... F-1
Access Control Server Vendor Selection .................................................................................. F-1
Dynamic Authentication Vendor Selection......................................................................... F-1
Issuer Program Enrollment ...................................................................................................... F-1
Testing Requirements............................................................................................................... F-1
Testing Process .................................................................................................................. F-2
Enrollment Screen/Marketing Material Review .................................................................. F-2
Completion of Testing ....................................................................................................... F-2
SecureCode in Production........................................................................................................ F-2
Certificate Request Process ................................................................................................ F-2
Loading Card Ranges ......................................................................................................... F-2
Directory Server Update Schedule ..................................................................................... F-3
Issuer Program Launch ...................................................................................................... F-3

Appendix G AAV Validation Service Implementation Process .....................G-i

Overview ................................................................................................................................ G-1
Prerequisites ..................................................................................................................... G-1
Issuer Program Enrollment ..................................................................................................... G-1
Key Exchange Process ............................................................................................................ G-2
Testing Requirements.............................................................................................................. G-2
Authorization Testing........................................................................................................ G-2
AAV Key Validation........................................................................................................... G-3
AAV Validation Service in Production ..................................................................................... G-3

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 v
Chapter 1 Overview
This chapter provides a general overview of the MasterCard® SecureCode™ Electronic Commerce
program.

MasterCard and E-commerce ......................................................................................................... 1-1

Maestro and E-commerce .............................................................................................................. 1-1

MasterCard Debit ........................................................................................................................... 1-2

MasterCard SecureCode Program ................................................................................................... 1-2

Typical Payment Transaction Participants...................................................................................... 1-3

Cardholder ............................................................................................................................... 1-4
Issuer ....................................................................................................................................... 1-4
Merchant .................................................................................................................................. 1-4
Acquirer ................................................................................................................................... 1-4

MasterCard SecureCode Program Platform..................................................................................... 1-5

What is UCAF and its Structure? ............................................................................................. 1-5
UCAF Transport in MasterCard Authorization Messages .................................................... 1-6
DE 48, Subelement 42 (Electronic Commerce Security Level Indicator)...................... 1-6
DE 48, subelement 43 (Universal Cardholder Authentication Field)............................ 1-7
Sample DE 48 Contents ............................................................................................... 1-7
Properly Coded DE 48 UCAF fields ....................................................................... 1-7
Improperly Coded DE 48 UCAF Fields .................................................................. 1-8
What is an AAV?....................................................................................................................... 1-9
MARP Exception ................................................................................................................ 1-9
What is a Merchant Plug-In? .................................................................................................... 1-9

Rules to Support UCAF Liability Shift ............................................................................................ 1-9

Global Liability Shift Program ................................................................................................ 1-10
Merchant Only Liability Shift Program ................................................................................... 1-10
Liability Shift Rule Summary .................................................................................................. 1-11

UCAF Compliance Requirements................................................................................................. 1-13

Authorization Requirements................................................................................................... 1-13
Debit/Single Message System Requirements.......................................................................... 1-15
Clearing Requirements........................................................................................................... 1-15

Enrollment Requirements............................................................................................................. 1-15

Maintenance Requirements.................................................................................................... 1-16

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 1-i
Overview

Participation Responsibilities ....................................................................................................... 1-16

Responsibilities for all Members ........................................................................................... 1-16
Issuer Responsibilities............................................................................................................ 1-17

MasterCard SecureCode Compliance and Functional Testing....................................................... 1-18

MasterCard SecureCode Program Enrollment Procedure ............................................................. 1-18

MasterCard Support ..................................................................................................................... 1-19

Project Management Support................................................................................................. 1-19
Regional MasterCard Office Support...................................................................................... 1-19
Additional References ............................................................................................................ 1-19
MasterCard SecureCode Program Publications................................................................. 1-19
MasterCard Authorization Specification Publications ....................................................... 1-20
Additional MasterCard Publications ................................................................................. 1-20
3-D Secure Protocol Specification Publications ............................................................... 1-20

©2005–2011 MasterCard. Proprietary. All rights reserved.

1-ii 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 Overview
MasterCard and E-commerce

MasterCard and E-commerce

E-commerce transactions account for a significant and increasing share of
MasterCard® gross dollar volume. The number of remote transactions is
increasing at a rate of more than 40 percent per year and growing. For
this reason, it is important to position e-commerce and mobile commerce
channels—Web access from PCs, PDAs, mobile phones, and other
wireless-enabled devices—to increase gross dollar volume profitability by using
security and authentication solutions that authenticate cardholders. This reduces
chargebacks and expenses that are associated with disputed transactions.

From a risk perspective, the current MasterCard electronic and mobile

transaction environment closely resembles traditional mail order/telephone
order (MO/TO) transactions. The remote nature of these transactions increases
risk, resulting in more cardholder disputes, and associated chargebacks.

These factors increase costs to all parties for managing disputes and
chargebacks. More than 70 percent of all chargebacks for e-commerce
transactions are associated with reason code 4837 (No Cardholder Authorization)
or reason code 4863 (Cardholder Not Recognized), and are currently estimated
at a cost of USD 34.00 per chargeback to the industry. These reason codes are
used where the consumer denies responsibility for the transaction and the
acquirer lacks evidence of the cardholder’s authentication, or the consumer
does not recognize the transaction.

Proving that the cardholder conducted and authorized the transaction in a

virtual, non–face-to-face environment of electronic and mobile commerce has
been extremely difficult. The MasterCard® SecureCode™ program is designed to
provide the infrastructure for an issuer security solution that reduces problems
associated with disputed charges, offering the opportunity to authenticate the
cardholder at the time of purchase. Disputed charges affect all parties in a
transaction—issuer, acquirer, cardholder, and merchant.

Maestro and E-commerce

Low credit card penetration in many countries has led to the use of inefficient
payment forms like cash on delivery, check, and domestic transfer/automated
clearing house (ACH). MasterCard SecureCode will allow Maestro® cards to be
used for Internet purchases in a safe and secure environment. MasterCard
SecureCode allows Maestro to be the first fully-authenticated global debit brand
accepted on the Internet. Unless otherwise stated by domestic country rules,
all Maestro Internet transactions provide protection against chargebacks and
fraud if the transaction was authorized by the issuer..

MasterCard rules require any merchant who wishes to accept Maestro to

undertake MasterCard SecureCode on every Maestro transaction unless they
have applied and been accepted to the Maestro Advanced Registration Program
(MARP). MasterCard recommends that issuers deploy an authentication
solution for cardholders in order to have appropriate evidence of cardholder
participation in the case of a disputed transaction.

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 1-1
Overview
MasterCard Debit

MasterCard Debit
Issuers of Debit® MasterCard, either single or dual message should note that
the single message system is capable of supporting transport of the Universal
Cardholder Authentication value (UCAF). Issuers must ensure that authorization,
and clearing for dual message are compliant with the latest debit standards
available on the Member Publications product on MasterCard OnLine®. The
MasterCard SecureCode authentication program occurs before an authorization
takes place, therefore, it can be used to authenticate any MasterCard card.
Issuers should ensure that their systems can support the transport of the
Account Authentication Value (AAV) before proceeding with a MasterCard
SecureCode program.

MasterCard SecureCode Program

MasterCard SecureCode offers flexible, robust, and easy to implement solutions
for cardholder authentication. Because requirements vary from issuer to issuer,
MasterCard places a premium on flexibility, enabling issuers to choose from
a broad array of security solutions for authenticating their cardholders. These
solutions include password, smart card-based approaches, or other solutions
of their own choosing.

From a program perspective there are a number of decisions that an issuer has
to make prior to implementing MasterCard SecureCode.
• What is the issuer’s attitude to risk?
• When should you authenticate a transaction? Do you want to authenticate
every transaction or just those that fall into a certain risk profile? The
MasterCard Risk Based Authentication white paper may be relevant if a
percentage is preferred.
• How should you authenticate? See Chapter 7, Issuer Authentication Options
for a selection of possible Authentication options.
• How does this authentication strategy impact your current authorization
strategy?

The decision on authentication strategy will provide the shape of the issuer’s
SecureCode deployment and is, perhaps, the most important decision. This
decision will balance the following considerations:
• The cardholder experience that an issuer wants to support for their
cardholders. Just as card portfolios are segmented, authentication strategies
can also be developed offering multiple forms of authentication (for
example, SMS for youth, and display card for High Value).
• Cost of authentication
• Cost of fraud being experienced and projected
• Requirements from domestic regulators

When determining cost of deployment it is important to factor in the cost of

both “Know Your Customer” and “Identification and Verification” that affects
any opt in service deployed compared to the costs of a dynamic approach that
does not require an opt-in by the cardholder.

©2005–2011 MasterCard. Proprietary. All rights reserved.

1-2 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 Overview
Typical Payment Transaction Participants

The most common of these solutions for MasterCard and Maestro issuers is the
use of static or dynamic passwords. Dynamic password usage is typically based
on the Chip Authentication Protocol (CAP) that provides for the creation of a
one-time use cardholder authentication password. This scenario is similar to
what the cardholder experiences in the face-to-face environment using EMV
chip card and personal identification number (PIN). CAP is now available
in a number of form factors ensuring that a single CAP Issuer solution can
support SMS, Mobile Applications, Display Card and the traditional CAP models
using sleave devices. See Chapter 7, Issuer Authentication Options for more
information on authentication options. This program provides a seamless
integration of both EMV and 3-D Secure technologies that result in stronger
authentication than traditional static password solutions.

MasterCard SecureCode is the consumer-and-merchant-facing name for all

existing and new MasterCard cardholder authentication solutions. While
these solutions may each appear quite different on the surface, these various
approaches converge around the UCAF mechanism and share a number of
common features.

In every case, for example, two things occur:

1. MasterCard or Maestro cardholders are authenticated using a secure, private
code that is unique to them. With both password and CAP implementations
of MasterCard SecureCode, an authentication box appears on the order
confirmation page and prompts cardholders for their SecureCode. In
a password-based implementation, cardholders enter the SecureCode
previously registered with the issuer. With the CAP, cardholders insert their
smart card into a card reader and enter their PIN. The issuer has the option
to use a challenge as well. Then, the chip generates a value that cardholders
place into the issuer authentication window as the SecureCode.
2. The authentication data is transported from party-to-party via the MasterCard
UCAF mechanism.

For more information about the MasterCard SecureCode platform components,

see MasterCard SecureCode Program Platform in this chapter.

Typical Payment Transaction Participants

In a face-to-face retail transaction or MO/TO transaction, electronic processing
begins with the merchant or the acquirer. In a MasterCard SecureCode
transaction, the electronic processing begins with the cardholder. The following
paragraphs describe the bankcard payment participants that are involved in a
MasterCard SecureCode transaction.

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 1-3
Overview
Typical Payment Transaction Participants

Cardholder
A cardholder is an authorized user of a card issued by a licensed financial
institution. In the e-commerce environment, consumers and corporate
purchasers interact with merchants remotely, typically through personal
computers. However, these points of interaction are expanding to include new
devices such as mobile phones. A cardholder uses a payment card issued
by a licensed MasterCard financial institution. MasterCard SecureCode will
ensure that a cardholder’s identity is authenticated prior to the completion of a
purchase from a participating merchant.

Cardholders participating in MasterCard SecureCode are expected to feel more

confident when shopping online and being authenticated by their issuer.

Issuer
An issuer is a MasterCard financial institution customer that issues either only
MasterCard cards or MasterCard and Maestro cards. The issuer guarantees
payment for an authorized transaction using the payment card in accordance
with payment card brand regulations and local legislation. Specifically for
MasterCard SecureCode, the issuer is responsible for determining cardholder
eligibility to participate in the MasterCard SecureCode program, as well as
providing authentication services for eligible online purchases.

MasterCard and Maestro issuers can benefit from participating in MasterCard

SecureCode by increased transaction volume and value as consumer confidence
increases from cardholder authentication programs. MasterCard issuers can
benefit from lower dispute management and processing costs.

Merchant
A merchant is a retailer, or any other person, firm, or corporation that, pursuant
to a merchant agreement, agrees to accept MasterCard and/or Maestro cards
when properly presented. With MasterCard SecureCode, the merchant can
offer a cardholder an authenticated electronic interaction over the Internet. A
merchant that accepts payment cards must have a relationship with an acquirer.
Merchants can benefit from participating in MasterCard SecureCode in several
ways including reduced fraud and dispute costs, increased transaction volume
and value, protection from unauthorized card use, and access to the Maestro
card base.

Acquirer
The MasterCard SecureCode program platform is comprised of a number
of layered components. As described in the following pages, each of the
components provides for specific authorization and authentication functionality
during the processing of a MasterCard SecureCode transaction.

©2005–2011 MasterCard. Proprietary. All rights reserved.

1-4 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 Overview
MasterCard SecureCode Program Platform

MasterCard SecureCode Program Platform

The MasterCard SecureCode program platform is comprised of a number of
layered components. As described in the following sections, each of the
components provides for specific authorization and authentication functionality
during the processing of a MasterCard SecureCode transaction. When combined,
the platform provides a mechanism for online merchants to receive a similar
global payment guarantee to one that brick-and-mortar retailers enjoy with
POS transactions.

What is UCAF and its Structure?

UCAF is a standard, globally interoperable method of collecting cardholder
authentication data at the point of interaction across all channels, including the
Internet and mobile devices.

Within the MasterCard authorization networks (that is the Single Message

and Dual Message System, and RSC) UCAF is a universal, multi-purpose data
transport infrastructure that is used to communicate authentication information
among cardholder, issuer, merchant, and acquirer communities. It is a variable
length, 32-position field with a flexible data structure that can be tailored to
support the needs of a variety of issuer security and authentication approaches.

The generic structure of UCAF is illustrated as follows:

The control byte contains a value that is specific to each security application.
MasterCard is responsible for assigning and managing UCAF control byte values
and the structure of UCAF application-specific data. Other solutions that use
UCAF for authentication collection and transport will be assigned their own
control byte value and the structure of the application-specific data will be
tailored to support the specifics of the security protocol.

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 1-5
Overview
MasterCard SecureCode Program Platform

In most UCAF implementations, the application-specific data is defined as binary

data with a maximum length of 24 binary bytes including the control byte.
However, there are some restrictions in the various MasterCard authorization
networks regarding the passing of binary data in the authorization messages.
As a result, all UCAF data generated by SPA algorithm-based MasterCard
SecureCode implementations must be Base64 encoded at some point prior to
being included in the authorization message. The purpose of this encoding is
to produce a character representation that is approximately 33 percent larger
than the binary equivalent. For this reason, the UCAF field is defined with a
maximum length of 32 positions. For more information about Base64 coding,
see Appendix A, SecureCode SPA Algorithm Specifications.

The current SecureCode control byte definitions include:

Base64
Encoded Hexadecimal
Usage Value Value
3-D Secure SPA AAV for first and subsequent
j x’8C’
transactions

3-D Secure SPA AAV for attempts h x’86’

Issuers with merchants participating in the MasterCard Advance Registration

Program (MARP), should also see MARP Merchant Use of MasterCard
SecureCode in Appendix E, MasterCard Advance Registration Program.

UCAF Transport in MasterCard Authorization Messages

MasterCard has designated specific subelements within data element (DE) 48
(Additional Data—Private Use) for the transport of UCAF-related data and
associated indicators in authorization messages. The following sections describe
these subelements.

DE 48, Subelement 42 (Electronic Commerce Security Level Indicator)

The Electronic Commerce Security Level Indicator contains the fields

representing the security protocol and cardholder authentication type associated
with the transaction. MasterCard requires that subelement 42 be included, and
properly populated for all e-commerce transaction authorizations.

The preferred data values for SecureCode are:

Position Value Description

1—Security Protocol 2 Channel Encryption (for example, SSL)
2—Cardholder 1 Cardholder Certificate Not Used
Authentication

©2005–2011 MasterCard. Proprietary. All rights reserved.

1-6 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 Overview
MasterCard SecureCode Program Platform

Position Value Description

3—UCAF Collection 0 UCAF data collection not supported by the merchant
Indicator for this transaction
1 UCAF data collection is supported by the merchant,
but UCAF data was not populated (DE 48, SE 43
is not present)
2 UCAF data collection is supported by the merchant,
and UCAF data is present (DE 48, SE 43)
3 Merchant participates in MARP, Data collection is
supported and UCAF data (the MARP static AAV) is
present (DE 48, SE 43)

DE 48, subelement 43 (Universal Cardholder Authentication Field)

The UCAF contains the encoded MasterCard SecureCode issuer-generated

authentication data (collected by the merchant) resulting from all MasterCard
SecureCode fully-authenticated transactions.

This field is also used to carry the static AAV that has been supplied to a
merchant that has been accepted into MARP. For additional information about
MARP, see Appendix E, MasterCard Advance Registration Program.
NOTE
The UCAF field length is variable up to a maximum of 32 positions. All acquirers and issuers must
ensure that they can send and/or receive contents in this field up to the maximum length of 32.
Applications using this field, such as SecureCode, may provide contents that are less than the
maximum length. For MasterCard SecureCode specifically, this field will be 28 positions.

For additional information about the contents of this field for a MasterCard
SecureCode authorization request message, see What is an AAV? in this chapter.

Sample DE 48 Contents

Following are samples of different DE 48 contents.

Properly Coded DE 48 UCAF fields

The following are examples of properly coded UCAF fields within a MasterCard
SecureCode authorization request message. The content of the DE 48,
subelement 42 is underlined.

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 1-7
Overview
MasterCard SecureCode Program Platform

Scenario Sample DE 48
MARP 5MARPPROGRAM9999999999999999
Fully authenticated T420701032124328jHyn+7YFi1EUAREAAAAvNUe6Hv8
authorization =820252
NOTE
The UCAF field (DE 48, subelement 43) is a variable
length field up to a maximum of 32 positions. The
MasterCard SecureCode AAV, in this case, is 28
characters in length. There must be no padding or
trailing spaces in the UCAF field.
Unauthenticated T42070103211820252
authorization from UCAF
enabled merchant
Unauthenticated T42070103210820252
authorization from
non-UCAF enabled
merchant

Improperly Coded DE 48 UCAF Fields

The following are examples of improperly coded UCAF fields within a

MasterCard SecureCode authorization request message. The content of the
DE 48, subelement 42 is underlined.

Scenario Sample DE 48
UCAF data field is T420701032124332jJJLtQa+Iws8AREAEbjsA1MAAAA= 820252
improperly padded The UCAF field (SE 43) is a variable length field up to a
maximum of 32 positions. The MasterCard SecureCode AAV is
28 characters in length. There must be no padding or trailing
spaces in the UCAF field.
Unknown Control T4207010321243328CC744DB69D5739CFE0100008
Byte and invalid EA89433820252
length indicator The contents of the UCAF data field is not properly Base64.
Instead the field contains a character representation of the
hex SecureCode AAV. The first character must be one of the
documented control bytes.
UCAF data field T42001032128701P4320Æ×ç¥ïXŠ ’ © ½ë9203123
contains binary The Security Level Indicator (DE 48, SE 42) is required when
AAV data instead UCAF data (DE 48, SE 43) is present in the message. This
of Base64 encoded results in a Banknet format error. Also, the UCAF data content
data is binary and not Base64 encoded.

©2005–2011 MasterCard. Proprietary. All rights reserved.

1-8 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 Overview
Rules to Support UCAF Liability Shift

What is an AAV?
The Accountholder Authentication Value (AAV) is a MasterCard SecureCode
specific token that uses the UCAF field for transport within MasterCard
authorization messages. It is generated by the issuer and presented to
the merchant for placement in the authorization request upon successful
authentication of the cardholder.

In the case of a chargeback or other potential dispute processing, the AAV is

used to identify the processing parameters associated with the transaction.
Among other things, the field values will identify the:
• Issuer ACS that created the AAV
• Sequence number that can positively identify the transaction for that location
• Secret key used to create the Message Authentication Code (MAC), which
is a cryptographic method that ensures AAV data integrity, and binds the
entire AAV structure to a specific PAN.

MARP Exception
For merchants that have qualified to participate in MARP, MasterCard assigns
a static AAV that conforms to the same format as an issuer-generated AAV.
MasterCard publishes regular bulletins to ensure issuers have a current, and
complete list of assigned static AAVs. See MasterCard OnLine for the latest
bulletin and Appendix E, MasterCard Advance Registration Program for more
information about MARP.

What is a Merchant Plug-In?

A merchant plug-in is a software application that is developed and tested to be
compliant with the 3-D Secure protocol and interoperable with the MasterCard
SecureCode infrastructure.

The plug-in application is typically provided by a technology vendor and

integrated with the merchant’s commerce server. It serves as the controlling
application for the processing of 3-D Secure messages.

As part of the MasterCard SecureCode infrastructure requirements, all merchant

endpoints must implement application software capable of processing 3-D
Secure messages. An endpoint is described as any merchant or merchant
processor platform, which directly connects to the MasterCard SecureCode
infrastructure.

Rules to Support UCAF Liability Shift

In support of the MasterCard SecureCode program, MasterCard has implemented
both global and regional liability shift programs governing specific fraud-related
chargeback reason codes. This section provides an overview of the UCAF
liability shift programs in effect as of the date of publication. For more
information, please refer to the Chargeback Guide.

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 1-9
Overview
Rules to Support UCAF Liability Shift

E-commerce Rules are provided in the Maestro Global Rules available on

MasterCard OnLine™. Issuers should reference this publication for full details
of the responsibilities and requirements when undertaking e-commerce
transactions and the for the benefits of MasterCard SecureCode with this product.
NOTE
Unless accepted into MARP, all merchants that accept Maestro online for payment must be
SecureCode enabled. MARP participating merchants will not undertake SecureCode on every
transaction. Where full SecureCode is not undertaken and the merchant relies on MARP, liability will
rest with the merchant. When full SecureCode is undertaken by a merchant qualified for MARP,
the liability will follow the standard SecureCode liability rules.

DEFINITION
An intraregional transaction is one in which the acquiring institution and issuing institution are in
the same MasterCard region, for example, the U.S., Canada, Europe, Asia Pacific, South Asia/Middle
East/Africa, and the Latin America/Caribbean regions.
An interregional transaction is one in which the acquiring institution and the issuing institution
are in different MasterCard regions.

Global Liability Shift Program

The issuer may not effect a chargeback under chargeback reason code 4837
(Cardholder Not Authorized), 4863 (Cardholder Not Recognized—Potential
Fraud), or 4849 (Questionable Merchant Activity) for qualifying e-commerce
transactions when:
• The merchant is UCAF-enabled for the transaction;
• The issuer provided the UCAF data for the transaction;
• All other electronic commerce Authorization Request/0100 message and
clearing requirements were satisfied; and
• The Authorization Request Response/0110 message reflected the issuer’s
approval of the transaction.

If the issuer determines that the UCAF data provided by the acquirer in the
Authorization Request/0100 message is not identical to the UCAF data created
for that transaction, the issuer’s right of chargeback under these reason codes
is preserved.

The liability shift program applies to all qualifying transactions globally.

Merchant Only Liability Shift Program

The issuer may not effect a chargeback reason code 4837 (Cardholder Not
Authorized) or chargeback reason code 4863 (Cardholder Not Recognized)
when only the merchant supports MasterCard SecureCode.

In these cases, the liability for e-commerce transactions shifts from the acquirer
to the issuer when:
• The merchant is UCAF-enabled for this transaction; and

©2005–2011 MasterCard. Proprietary. All rights reserved.

1-10 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 Overview
Rules to Support UCAF Liability Shift

• All other e-commerce Authorization Request/0100 messages and clearing

requirements were satisfied; and
• The Authorization Request Response/0110 message reflected the issuer’s
approval of the transaction.

This liability shift program currently applies to all qualifying intraregional

transactions within the Europe, Asia Pacific, South Asia/Middle East/Africa, U.S.,
and the Latin America/Caribbean regions, as well as all qualifying interregional
transactions. Commercial card products currently are excluded from the
interregional liability shift program.

Liability Shift Rule Summary

Issuers should always check the Chargeback Guide for the current liability shift
rules, particularly for any variance at a country or product level.

The following table summarizes the applicability of the global and merchant
only liability shift rules for qualifying transactions across the MasterCard regions.

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 1-11
Overview
Rules to Support UCAF Liability Shift

Liability Shift—Consumer Cards

* = Merchant Only Liability Shift

Issuing Regions

U.S. CAN EUR LA/C AP SAMEA

Acquiring U.S. * * * * * *
Regions
CAN * * * * * *

EUR * * * * * *

LA/C * * * * * *

AP * * * * * *

SAMEA * * * * * *

Commercial cards remain excluded from the Global Merchant Only Liability
shift but are included on an intraregional basis for the Europe, Asia Pacific,
South Asia/Middle East/Africa, and the Latin America/Caribbean regions.

Liability Shift—Commercial Cards

* = Merchant Only Liability Shift
^ = Fully Authenticated Liability Shift

Issuing Regions

U.S. CAN EUR LA/C AP SAMEA

Acquiring U.S. ^ ^ ^ ^ ^ ^
Regions
CAN ^ ^ ^ ^ ^ ^

EUR ^ ^ * ^ ^ *

LA/C ^ ^ ^ * ^ ^

AP ^ ^ ^ ^ * ^

SAMEA ^ ^ ^ ^ ^ *

Commercial cards remain excluded from the Global Merchant Only Liability
shift but are included on an intraregional basis for the Europe, Asia Pacific,
South Asia/Middle East/Africa, and the Latin America/Caribbean regions.

©2005–2011 MasterCard. Proprietary. All rights reserved.

1-12 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 Overview
UCAF Compliance Requirements

UCAF Compliance Requirements

Support for processing of UCAF transaction data is a co-requisite for all
MasterCard SecureCode issuer implementations. Maestro issuers are required to
support MARP, static AAV, and standard SecureCode AAV within authorization
if they support e-commerce. Maestro issuers should check to see if there are
regional requirements that require them to undertake e-commerce such as
the current mandate in the Europe region. For additional information, see
Appendix F, Issuer Implementation Process.

Authorization Requirements
MasterCard issuers and acquirers must modify their authorization systems
to support the required UCAF transaction data elements. Further, it is a
requirement that all qualifying transactions must be properly coded e-commerce
transactions.

The following table highlights the field requirements that are required for
coding of e-commerce authorizations. For more information about the coding of
UCAF data elements for non–e-commerce transactions, refer to the appropriate
authorization message specification document.

Data Element Comments

22 Point of Service Entry Mode
Subfield 01—POS Terminal Entry Mode 81—PAN entry via electronic
commerce, including chip

48 Additional Data—Private Use

TCC—Transaction Category Code Contains one of the following

values:
• T = All other non–face-to-face
transactions
• U = Unique (Refer to the
GCMS Reference Manual
for additional requirments
regarding the use of this value.
Subfields

42—Electronic Commerce Security Contains the security level in

Level Indicator (Mandatory) positions 1 and 2 and the UCAF
collection indicator in position 3
• Position 1 = Security Protocol
(for SecureCode, the value is
2—Channel)
• Position 2 = Cardholder
Authentication (for SecureCode,
the value is 1–Cardholder
Certificate Not Used)

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 1-13
Overview
UCAF Compliance Requirements

Data Element Comments

42—Electronic Commerce Security Position 3–UCAF Collection

Level Indicator (Mandatory) Indicator. Valid values are:
• 0 = UCAF data collection is not
supported by the merchant for
this transaction
• 1 = UCAF data collection is
supported by the merchant, but
UCAF data was not populated
(DE 48, subelement 43 is not
present)
• 2 = UCAF data collection is
supported by the merchant and
UCAF data must be populated
(DE 48, subelement 43)
• 3 = Merchant participates in
MARP and UCAF must be
populated with the MasterCard
assigned static AAV (DE 48, sub
element 43)

43—Universal Cardholder Contains either the encoded

Authentication Field (Conditional) MasterCard SecureCode
issuer cardholder generated
authentication data, if collected.
MasterCard Worldwide Network
will edit for:
• The presence or absence of
this field based on the value of
the UCAF Collection Indicator,
or
• Merchants participating in
MARP, the fixed AAV assigned
by MasterCard

61 Point-of-Service Data Contains the following values to

uniquely identify the ecommerce
transaction.

Subfields

2—POS Terminal Location 2 = Off premises of card acceptor

facility (cardholder terminal
including home PC, mobile phone,
PDA)

4—POS Cardholder Presence 5 = Electronic order (home PC,

Internet, mobile phone, PDA
10—Cardholder Activated Terminal 6 = Authorized Level 6 CAT:
Level Electronic commerce

©2005–2011 MasterCard. Proprietary. All rights reserved.

1-14 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 Overview
Enrollment Requirements

Debit/Single Message System Requirements

Issuers and acquirers of Debit MasterCard and Maestro cards must modify their
authorization systems to support UCAF transaction data. For more information
about requirements to support UCAF, refer to the Single Message System
Specifications manual.

Maestro issuers must support MARP static AAV and standard SecureCode AAV
within authorization if they support e-commerce. Maestro issuers should check
for any regional requirements that mandates the use of e-commerce such as the
current mandate in the Europe region.

Clearing Requirements
In support of the MasterCard SecureCode program, MasterCard requires that
acquiring members must support changes to the Global Clearing Management
System (GCMS) clearing records in support of associated interchange rate
programs.

MasterCard requires that all clearing and chargeback records associated with an
e-commerce authorization message contain the DE 48, private data subelement
0052 (Electronic Commerce Security Level Indicator). Failure to include this
field will result in the message being rejected by GCMS with an edit error. The
contents of this field must be consistent with the value of the DE 48, subelement
42, position 3 in the corresponding authorization message. In addition, UCAF
interchange rate qualification for all transactions acquired in the U.S. region are
subject to interchange compliance edits.
NOTE
Issuers should refer to the latest Interchange Manual for their region to determine what interchange
is applied for Full UCAF and Merchant UCAF transactions.

Enrollment Requirements
Following are issuer requirements to participate in the MasterCard SecureCode
Electronic Commerce Program:
• All participating members must complete both a general enrollment form,
and the issuer program enrollment form.
See MasterCard SecureCode Program Enrollment Procedure in this chapter
for additional information.
• Select a vendor or service provider to provide the required infrastructure
(for example, merchant plug-ins, access control servers, and more.)
• Assign a program manager to manage, test, and integrate the current system
with MasterCard SecureCode.
• Ensure all authorization and clearing systems can support UCAF data. For
additional information, see UCAF Compliance Requirements in this chapter.

The MasterCard e-commerce program manager will review and approve

member enrollment materials.

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 1-15
Overview
Participation Responsibilities

Maintenance Requirements
Issuers and acquirers should regularly review the content of their existing
registration document, especially when key individuals noted in the registration
move to other roles or leave the organization. If changes are required, a
new enrollment form should be completed and submitted for amendment of
the current registration.

Participation Responsibilities
The following sections explain member roles and responsibilities for
participation in the MasterCard SecureCode program. These roles and
responsibilities are applicable for both MasterCard and Maestro issuers.

Responsibilities for all Members

The following paragraphs outline the responsibilities for all issuers participating
in the MasterCard SecureCode program.

Member Agreement to Abide by MasterCard Rules and Policies

MasterCard agrees to permit a member to participate in transactions involving

the MasterCard SecureCode program in return for which member agrees to be
bound by all of the rules, policies, and procedures relating to the MasterCard
SecureCode program in effect at the time the transactions are conducted
whether formally enacted by MasterCard or communicated through brochures,
statements, guidelines or other member communications. Without limiting the
foregoing, member specifically acknowledges and agrees to be bound by the
MasterCard implementation of MasterCard SecureCode and the MasterCard
SecureCode Certificate Policy Statement (CPS). Member understands and
acknowledges that all rules and policies relating to the MasterCard SecureCode
program and electronic commerce may be amended from time to time and are
subject to change without notice by MasterCard.

No Representations or Warranties

MasterCard makes no representations or warranties whatsoever with respect

to the MasterCard SecureCode program, including without limitation any
software, hardware or other technology built to MasterCard standards, any
services provided by it, or any other matter relating to or arising out of
any implementation of the MasterCard SecureCode specifications. Without
limiting the foregoing, MasterCard specifically disclaims all representations and
warranties as to its operation of the MasterCard Certificate Authority. MasterCard
specifically disclaims all implied warranties of merchantability, fitness for a
particular purpose and non-infringement of third party intellectual property
rights with respect to any and all MasterCard SecureCode implementations
whether or not MasterCard has been advised, has reason to know, or is
otherwise in fact aware of any information regarding the foregoing.

Indemnity and Limitation of Liability

©2005–2011 MasterCard. Proprietary. All rights reserved.

1-16 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 Overview
Participation Responsibilities

Member agrees to indemnify and hold harmless MasterCard and its directors,
officers, employees, agents and affiliates against any and all claims arising out
of member’s participation in the MasterCard SecureCode program. Member
agrees that it shall not assert any claim or action against MasterCard arising out
or otherwise connected in any way with the MasterCard SecureCode program
and hereby waives all such claims against MasterCard and releases MasterCard
from and against any and all liability for such claims. Without limiting the
foregoing, member specifically waives and releases MasterCard from any and
all claims arising out of its operation of the MasterCard SecureCode certificate
authority. The foregoing limitations of liability shall apply to any claim or cause
of action under law or equity whatsoever, including contract, warranty, strict
liability, or negligence, even if MasterCard has been notified of the possibility
of such claims. The entire liability of MasterCard to member for any and all
acts, errors, and omissions relating to or arising out of or in connection with the
MasterCard SecureCode program shall be limited to USD 1,000.

License Agreement for Specifications

If member executes a license agreement for any MasterCard specifications

related to the MasterCard SecureCode Program (whether by written, click-wrap,
or shrink-wrap agreement), the terms of such license agreement shall have
precedence and govern over the terms in the Participation Responsibilities
section of this chapter.

Acceptance of Terms

The signing of enrollment forms indicates that the member understands and
agrees to the terms and conditions set forth herein including but not limited to
those above. The member acknowledges that its acceptance of these terms and
conditions is relied upon by MasterCard in permitting member’s participation in
the MasterCard SecureCode program.

Issuer Responsibilities
Issuers are responsible for the following:
• Soliciting cardholders to participate in the MasterCard SecureCode program.
• Adhering to:
– MasterCard requirements for information and data security, including
but not limited to protection of MasterCard card numbers, Maestro
account numbers, cardholder enrollment information and management
and protection of secret cryptographic keys. For more information, refer
to the SecureCode ACS Security Requirements manual.
– Applicable usage guidelines as published in MasterCard SecureCode
Program Identifier Usage Guidelines.
– Published requirements regarding authentication and enrollment pages
as documented in the MasterCard SecureCode Cardholder Interface
Requirements manual.
• Reporting to MasterCard on experiences and progress with cardholder use
of MasterCard SecureCode products, shopping experiences, and related
market research information.
• Providing:

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 1-17
Overview
MasterCard SecureCode Compliance and Functional Testing

– Primary customer service for cardholders.

– Testing resources to test the ability to receive Authorization
Request/0100 (for MasterCard and Maestro cards in the Europe region)
and Authorization Request/0200 (for Maestro cards) messages and sends
Authorization Request Response/0110 (for MasterCard cards and Maestro
cards in the Europe region) and Authorization Request Response/0210
(for Maestro cards) messages containing data specific to e-commerce.

MasterCard SecureCode Compliance and Functional Testing

MasterCard has developed vendor compliance testing, as well as issuer and
merchant functional testing, to ensure vendor products and member and
merchant implementations are compliant and successfully interoperate with all
MasterCard SecureCode platforms and infrastructure.

All vendors, merchant endpoints, and issuers are required to complete the
designated testing process prior to launch. More information regarding testing
is available from [email protected].

MasterCard SecureCode Program Enrollment Procedure

Following is an outline of the MasterCard SecureCode enrollment procedure:

This section is for understanding the member roles and responsibilities.

1. Complete and sign the enrollment forms for the MasterCard SecureCode
Electronic Commerce Program.
– To access from the Main Menu on MasterCard OnLine®, select
Resources, and then click Business Forms.
– Forms can also be requested by e-mail message to
[email protected].
2. Submit the forms in both hard-copy, and electronically using the following
methods:
– Submit completed and signed hard-copy forms to the authorized
MasterCard Regional Electronic Commerce Representative for review
and approval. See Appendix B, Contact Information for a list of contacts.
– Submit the enrollment forms electronically by e-mail message to
[email protected].

After the authorized representative receives the completed and signed

enrollment forms, the following occurs:
1. The regional representative reviews the enrollment forms for completeness,
accuracy, and signatures. Upon review and approval, the regional
representative signs the forms and submits them to the MasterCard
Electronic Commerce Group in New York for review and approval.
2. The MasterCard Electronic Commerce Group will review and approve the
forms and forward them to the appropriate internal groups for review and
approval. If necessary, site visits are scheduled.
3. The MasterCard Electronic Commerce team in New York will provide testing
details and instructions to program contacts listed on the enrollment forms.

©2005–2011 MasterCard. Proprietary. All rights reserved.

1-18 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 Overview
MasterCard Support

4. Upon approval by all the MasterCard Electronic Commerce groups, the

signed enrollment forms will be returned to the regional representatives for
distribution to the member.

For more details about implementation, see Appendix F, Issuer Implementation

Process.

MasterCard Support
MasterCard will provide support as explained below to members enrolled in
the MasterCard SecureCode program.

Project Management Support

The MasterCard Electronic Commerce team has been involved in numerous
MasterCard SecureCode projects throughout the world. These MasterCard
team members are available to provide guidance and advice about member
implementation, subject to personnel availability. For specific contact
information, see Appendix B, Contact Information.

Regional MasterCard Office Support

Regional MasterCard offices will provide direction and planning support subject
to personnel availability.

All advice and information provided by MasterCard is subject to the disclaimers

and limitations on liability.

Additional References
Unless otherwise noted, all publications are available from the Member
Publications section of MasterCard OnLine.

MasterCard SecureCode Program Publications

MasterCard SecureCode program publications include:
• Licensed publications available by e-mail request to
[email protected]:
– SPA Algorithm for the MasterCard Implementation of 3-D Secure
– MasterCard SecureCode 3-D Secure Chip Authentication Programme
– SecureCode ACS Security Requirements
– MasterCard SecureCode Production Procedures
• Request access to the MasterCard SecureCode Toolkit using either of the
following methods:
– MasterCard SecureCode resource center of MasterCard OnLine.
– mastercard.com—www.mastercard.com/us/merchant/secu-
rity/what_can_do/SecureCode/toolkit/SecureCode.html#Order the
SecureCode Program Toolkit

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 1-19
Overview
MasterCard Support

NOTE
The documentation regarding the industry standard for 3-D Secure is not available from MasterCard.
These documents must be sourced under license from the standard owner.

MasterCard Authorization Specification Publications

MasterCard Authorization specification publications are as follows:
• Customer Interface Specification
• Regional Service Center Message Specification Manuals
• Single Message Specifications
• Quick Reference Booklet (contains state, country, and currency codes)
• MasterCard SecureCode Web training and information presentations are
available at www.mastercard.com/securecode360.
• White paper on Risk-based Authentication is available at
www.mastercard.com/us/company/en/whatwedo/resources.html.
• Issuer Best Practice Guide for SecureCode available at
www.mastercard.com/us/company/en/whatwedo/resources.html.

Additional MasterCard Publications

Additional MasterCard publications that may be helpful include:
• GCMS Reference Manual
• Maestro Global Rules
• Interchange and Service Fees (Europe region)
• Interchange Programs and Rates (outside the Europe region)

3-D Secure Protocol Specification Publications

3-D Secure Protocol Specification documents include:
• 3-D Secure Functional Requirements Merchant Server Plug-In v1.0.2 6 May
2006
• 3-D Secure Functional Requirements Access Control Server v1.0.2 6 May
2006

©2005–2011 MasterCard. Proprietary. All rights reserved.

1-20 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
Chapter 2 3-D Secure Solution Overview
This section provides an overview of the MasterCard implementation of 3-D Secure for MasterCard®
cards and Maestro® cards, including cardholder enrollment and payer authentication.

Overview ....................................................................................................................................... 2-1

Components................................................................................................................................... 2-1
Issuer Domain.......................................................................................................................... 2-1
Cardholder Browser and Related Cardholder Software ..................................................... 2-2
Enrollment Server .............................................................................................................. 2-2
Access Control Server ........................................................................................................ 2-2
AAV Validation Server/Process........................................................................................... 2-2
Acquirer Domain ..................................................................................................................... 2-2
Merchant Plug-In ............................................................................................................... 2-2
Signature Validation Server ................................................................................................ 2-3
Interoperability Domain........................................................................................................... 2-3
Directory Server ................................................................................................................. 2-3
Certificate Authority ........................................................................................................... 2-3
Transaction History Server ................................................................................................. 2-3
Attempts Server.................................................................................................................. 2-4

Messages........................................................................................................................................ 2-4
Card Range Request/Response ................................................................................................ 2-4
Verification Request/Response................................................................................................. 2-4
Payer Authentication Request/Response.................................................................................. 2-4
Payer Authentication Transaction Request/Response .............................................................. 2-5

Cardholder Enrollment Process...................................................................................................... 2-5

Enrollment—Static Password ................................................................................................... 2-5
Standard Enrollment .......................................................................................................... 2-6
Issuer CSR-assisted Enrollment ........................................................................................ 2-11
Activation-During-Shopping Enrollment .......................................................................... 2-13

Cardholder Authentication ........................................................................................................... 2-15

Sample Cardholder Authentication Process ........................................................................... 2-15

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 2-i
 3-D Secure Solution Overview
Overview

Overview
Cardholder authentication is the process of verifying cardholder account
ownership during a purchase transaction in an online electronic commerce
environment. All MasterCard® SecureCode™ solutions define and provide a
base level of security around performing this authentication process. For this
solution specifically, MasterCard is deploying its own implementation of 3-D
Secure under the MasterCard SecureCode program branding for MasterCard®
and Maestro®. This implementation of 3-D Secure includes support for the SPA
algorithm and Universal Cardholder Authentication Field (UCAF) without any
changes to the 3-D Secure specification, messages, or protocol.

The components described below are organized according to requirements that

fall within the issuer, acquirer, and interoperability domains associated with
the payment process.
• Issuer Domain—Systems and functions of the card issuing financial
institutions and its customers.
– Cardholder Browser
– Related Cardholder Software
– Enrollment Server
– Access Control Server
– Accountholder Authentication Value (AAV) Validation Server/Process
• Acquirer Domain—Systems and functions of the acquirer and its customers.
– Merchant Plug-In
– Signature Validation Server
• Interoperability Domain—Systems, functions, and messages that allow the
Issuer Domain and Acquirer Domain to interoperate. These components
will be globally operated and managed by MasterCard.
– Directory Server
– Certificate Authority

Components
Following is information about components related to the Issuer Domain,
Acquirer Domain, and Interoperability Domain.

Issuer Domain
The Issuer Domain is comprised of the:
• Cardholder browser and related software
• Enrollment server
• Access control server
• AAV validation server/proces

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 2-1
3-D Secure Solution Overview
Components

Cardholder Browser and Related Cardholder Software

The Cardholder browser acts as a conduit to transport messages between the
Merchant Server Plug-In (in the Acquirer Domain) and the Access Control
Server (in the Issuer Domain). Optional cardholder software to support
implementations such as chip cards may also be included.

Both the browser and related software are considered to be off-the-shelf

components that do not require any specific modification to support 3-D Secure.

Enrollment Server
The purpose of the enrollment server is to facilitate the process of cardholder
enrollment for an issuer’s implementation of 3-D Secure under the MasterCard
SecureCode program. The server will be used to perform initial cardholder
authentication, as well as administrative activities such as SecureCode resets
and viewing 3-D Secure payment history. In some cases, the enrollment server
and the access control server may be packaged together.

Access Control Server

The access control server serves two basic, yet vital, functions during the course
of a MasterCard SecureCode online purchase. First, it will verify whether a given
account number is enrolled in the MasterCard SecureCode program. Secondly,
it will facilitate the actual cardholder authentication process.

AAV Validation Server/Process

This server or process will be used to perform validation of the cardholder
authentication data received by the issuer’s authorization system in the
authorization messages. MasterCard recommends issuers validate the AAV
contained in the authorization message prior to authorization decisioning.
This is considered a best practice, although not required. For details about
“on-behalf-of” AAV Validation offered by MasterCard, see Appendix G, AAV
Validation Service Implementation Process.

Acquirer Domain
The Acquirer Domain is comprised of the:
• Merchant plug-in
• Signature validation server

Merchant Plug-In
The merchant server plug-in creates and processes payer authentication
messages and then returns control to the merchant software for further
authorization processing. The plug-in is invoked after the cardholder finalizes
the purchase request, which includes selecting the account number to be used,
and submitting the order but prior to obtaining authorization for the purchase.

©2005–2011 MasterCard. Proprietary. All rights reserved.

2-2 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 3-D Secure Solution Overview
Components

Signature Validation Server

The signature validation server is used to validate the digital signature on
purchase requests that have been successfully authenticated by the issuer. This
server may be integrated with the merchant plug-in or may be a separately
installed component.

Interoperability Domain
The Interoperability Domain is comprised of the
• Directory server
• Certificate authority
• Transaction history server
• Attempts server

Directory Server
The MasterCard SecureCode global directory server provides centralized
decision-making capabilities to merchants enrolled in the MasterCard
SecureCode program. Based on the account number contained in the merchant
enrollment verification request message, the directory will first determine
whether the account number is part of a participating MasterCard or Maestro
issuer’s card range. It will then direct eligible requests to the appropriate
issuer’s access control server for further processing.

All implementations of this issuer platform must use the MasterCard SecureCode
global directory server for processing MasterCard and Maestro® transactions.

Certificate Authority
The MasterCard Certificate Authority is used to generate and distribute all
private hierarchy end-entity and subordinate certificates, as required, to the
various components across all three domains.

These certificates include:

• MasterCard Root certificate (used for both MasterCard and Maestro)
• SSL Server and Client certificates issued under the MasterCard hierarchy
• Issuer Digital Signing certificates issued under the MasterCard hierarchy
• In addition, SSL certificates based on a public root hierarchy are required.
These certificates are not issued by the MasterCard Certificate Authority and
must be obtained from another commercially available certificate-issuing
provider.

Transaction History Server

The Authentication History Server is a central repository of all authentication
activity occurring out of band from MasterCard Authorization systems.
The MasterCard SecureCode infrastructure does not currently support this
component server, but may in the future.

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 2-3
3-D Secure Solution Overview
Messages

Attempts Server
The MasterCard SecureCode infrastructure does not support this component
server.

Messages
The card range request/response, the verification request/response, the payer
authentication request/response, and the payer authentication transaction
request/response are all message types associated with the 3-D Secure Solution
process.

Card Range Request/Response

Message Pair: CRReq/CRRes—For performance reasons, the Merchant
Server Plug-In has the capability to cache the card ranges contained in the
Directory, which indicate issuer participation in 3-D Secure. The Card Range
Request/Response messages are used by the Merchant Server Plug-In as a way
to request updates to the cache from the Directory. MasterCard discourages
the use of caching and recommends that merchants check issuer participation
against the directory server—real time—for each transaction.

Verification Request/Response
Message Pair: VEReq/VERes—The first step in the payer authentication process
is to validate that the cardholder account number is part of an issuer’s card
range, which is participating in 3-D Secure. The Verification Request/Response
messages are sent from the Merchant Server Plug-In to the Directory to check
card range eligibility. If the specified account number is contained within a
SecureCode eligible card range, this message is then sent from the Directory to
the Access Control Server to check if the specific account number is enrolled
and active to participate in 3-D Secure.

For those merchants that cache the contents of the MasterCard SecureCode
directory server, this message is not used if the cache indicates that the issuer
is not enrolled in 3-D Secure. If the cache does indicate that the issuer is
enrolled, or if no cache is being maintained, this message must be formatted
and processed as described.

Payer Authentication Request/Response

Message Pair: PAReq/PARes—Once it has been determined that a cardholder
is enrolled to participate in 3-D Secure, the actual process of payer
authentication is performed for each online purchase. The Payer Authentication
Request/Response messages are sent from the Merchant Server Plug-In to the
Access Control Server to initiate the actual authentication. It is at this point in
the process where the cardholder will be presented with an authentication
window and asked to enter his or her SecureCode.

©2005–2011 MasterCard. Proprietary. All rights reserved.

2-4 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 3-D Secure Solution Overview
Cardholder Enrollment Process

The Access Control Server will perform authentication and, if successful,

generate an Accountholder Authentication Value (AAV). It is returned to the
merchant within the PARes message. For successfully authenticated transactions,
this AAV must be sent by the merchant to the acquirer and forwarded to the
issuer as part of the authorization request.

Payer Authentication Transaction Request/Response

Message Pair: PATransReq/PATransRes—Following authentication, it may
be desirable to centralize storage of authentication requests for later dispute
processing. The Payer Authentication Transaction Request/Response messages
provide a record of this authentication activity sent from the ACS to the History
Server.

The MasterCard SecureCode global infrastructure does not support these

messages now, but may sometime in the future.

Cardholder Enrollment Process

The following section outlines the cardholder enrollment process for
SecureCode when an opt-in service such as static password is used. This will
be impacted by the decision on which authentication has been taken, and if
risk-based authentication has been implemented. Cardholder enrollment is not
required for some of these dynamic/risk-based methods of authentication. The
following section is therefore discussed on the basis that enrollment is required,
for example in the case if static password.

There are two primary types of interactions between a cardholder and the
issuer software:
• Enrollment—static password
• Purchase Transactions

Supplemental functionality is available through the issuer’s 3–D Secure Home

page, including:
• Account Management
• Reregistration
• Frequently Asked Questions (FAQs)
• Contact Details

Enrollment—Static Password
To shop with the assurance of 3-D Secure, a cardholder must enroll in the
program through the issuer. The enrollment process verifies the cardholder’s
identity and allows the cardholder to establish a SecureCode for authentication
while shopping online. Enrollment is typically required for static password,
when the cardholder is creating a password that will be used each time the
cardholder shops at a participating merchant.

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 2-5
3-D Secure Solution Overview
Cardholder Enrollment Process

There are three enrollment options:

• Standard enrollment
• CSR-assisted enrollment
• Activation-During Shopping (ADS) enrollment

All three methods may be implemented at the same time, although the
cardholder will only be required to enroll once.
NOTE
One-time password (OTP) via SMS or Chip Auntentication does not require cardholder enrollment.
For more information about OTP methods send an e-mail message to the MasterCard OAS team at
[email protected].

Standard Enrollment
The Standard Enrollment method is accessed through the issuer 3–D Secure
Home page, and allows cardholders to enroll before online shopping.

Figure 2.1 is the SecureCode landing page. The landing page is optional, and
is primarily used for issuers that support multiple:
• languages
• brands (MasterCard, Maestro, Visa®)
• portfolios (for example commercial and consumer) with different
configurations (different security questions or contact us information)

Figure 2.1—Customer Landing Page

©2005–2011 MasterCard. Proprietary. All rights reserved.

2-6 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 3-D Secure Solution Overview
Cardholder Enrollment Process

The Welcome page provides an overview of SecureCode, including a video

demonstration and links for cardholders to learn additional information such
as Frequently Asked Questions, Contact Us, Terms of Service, and Account
Management.

Figure 2.2—Cardholder Welcome Page

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 2-7
3-D Secure Solution Overview
Cardholder Enrollment Process

The Choose Registration Path page allows the cardholder to select either
Register (Standard Enrollment) or, if setup with a Temporary Access code
through CSR-Assisted Enrollment, Register with a Temporary Access Code.

Figure 2.3—Issuer Choose Registration Path

Figure 2.4—Cardholder Provides Card Number

©2005–2011 MasterCard. Proprietary. All rights reserved.

2-8 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 3-D Secure Solution Overview
Cardholder Enrollment Process

Cardholders enroll in their issuer’s SecureCode or through the 3–D Secure

enrollment Web site, which is configured and branded for that issuer. The
cardholder is required to provide personal information to satisfy the issuer’s
requirements for confirming identity.

Figure 2.5—Cardholder Confirms Identity

The enrollment site checks the credentials of the cardholder against the
cardholder profile data.

If the cardholder’s identity is confirmed the cardholder is prompted to create

a SecureCode and Personal Greeting for use during purchase authentication
sessions. This information will be used to authenticate the cardholder’s identity
when the cardholder attempts to purchase online at participating merchants.

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 2-9
3-D Secure Solution Overview
Cardholder Enrollment Process

Figure 2.6—Cardholder Creates SecureCode Password and Personal Greeting

The issuer enrollment server (ES) processes the enrollment and records the
SecureCode and Personal Greeting in the issuer database.

©2005–2011 MasterCard. Proprietary. All rights reserved.

2-10 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 3-D Secure Solution Overview
Cardholder Enrollment Process

Figure 2.7—Enrollment Confirmation

Issuer CSR-assisted Enrollment

In certain cases, it may be appropriate for the issuer’s customer service
representative (CSR) to manually enroll one of its cardholders. This is called
CSR-assisted enrollment, and might result from any of the following:
• The cardholder has attempted standard enrollment but was unsuccessful
in answering the identification questions (possibly due to inaccurate or
incomplete cardholder data provided by the issuer).
• The issuer may want to provide a higher level of service to V.I.P. cardholders.
• The cardholder calls the support phone number on the back of his card
and requests assistance.
• The cardholder has forgotten his SecureCode and calls for assistance to reset.

When a cardholder calls for assistance, the CSR verifies the cardholder identity
via the issuer’s regular identification procedure. The CSR then provides the
cardholder with a Temporary Access Code (TAC) and the hosted enrollment
site address. The cardholder navigates to the issuer’s 3–D Secure Home page
and uses the Temporary Access Code to enroll. The cardholder creates a
SecureCode and Personal Greeting to complete the enrollment.
NOTE
At initial setup, the issuer defines the number of days that the Temporary Access Code is valid. A
Temporary Access Code cannot be used for authentication while shopping and can be used only
once to enroll.

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 2-11
3-D Secure Solution Overview
Cardholder Enrollment Process

If the CSR manually enrolls a cardholder, the cardholder does not answer the
Web site identification questions. Instead the cardholder enters a temporary
access code. All other steps in the CSR-assisted enrollment process are the
same as standard enrollment. Refer to Figure 2.3.

Figure 2.8—Cardholder Enters Temporary Access Code

1. The cardholder confirms identity to an issuer CSR via telephone using the
issuer’s normal authentication procedures.
2. The issuer CSR adds the cardholder account data, if required, and the
Temporary Access Code to the application database. The issuer CSR
provides the cardholder with a Temporary Access Code and registration URL.
3. The cardholder accesses the hosted by MasterCard issuer enrollment site
and uses the Temporary Access Code to confirm identity. The cardholder
then creates a SecureCode.

The cardholder is always assigned a Temporary Access Code. Similar to an ATM

PIN assignment, the CSR can never see, assign, or update the actual SecureCode.

The cardholder can immediately begin to shop once the Assisted-enrollment

is complete.
CAUTION
The issuer CSR must verbally confirm the identity of the cardholder before assigning a Temporary
Access Code.

©2005–2011 MasterCard. Proprietary. All rights reserved.

2-12 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 3-D Secure Solution Overview
Cardholder Enrollment Process

Activation-During-Shopping Enrollment
Activation-During-Shopping (ADS) enrollment allows cardholders to register
for the SecureCode program while shopping using a process managed by
MasterCard OAS.

While making a purchase at a participating e-commerce merchant, the

cardholder enters the account number. The merchant verifies that the card
number is in an ADS eligible range and then sends a message through the
directory server to the issuer software (hosted by MasterCard OAS), informing
the OAS system that the cardholder is at the merchant site.

The issuer software checks to see if the cardholder is enrolled; if unenrolled,

the issuer software displays the first page of ADS at the merchant site to
the cardholder; the cardholder then successfully answers the identification
questions.

Figure 2.9—Cardholder Enrolls During Purchase

The issuer software displays the second page of ADS to the cardholder. The
cardholder creates a SecureCode and completes any additional information
requested by the issuer.

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 2-13
3-D Secure Solution Overview
Cardholder Enrollment Process

Figure 2.10—Cardholder Creates SecureCode

The merchant purchase confirmation page is displayed to the cardholder and

the transaction is completed as an authenticated transaction.

Option: Invite the cardholder to personalize the Personal Greeting and provide
an e-mail address at the standard enrollment site. This is achieved through
a window that will appear as the lowest open window available on the
cardholder’s desktop (as opposed to a pop-up which becomes the primary
window on the desktop).

Figure 2.11—Cardholder Enrollment Confirmation

©2005–2011 MasterCard. Proprietary. All rights reserved.

2-14 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 3-D Secure Solution Overview
Cardholder Authentication

NOTE
During ADS, a default Personal Greeting can be assigned by the Issuer software and uploaded to
MasterCard OAS and can be changed by the cardholder via account management on the enrollment
Web site. The Personal Greeting is a customizable message that assures the cardholder that the
Purchase Authentication screens are presented by their issuer.

Cardholder Authentication
Following is information about the cardholder authentication process.

Sample Cardholder Authentication Process

The sample flow that follows assumes that the cardholder has already enrolled
in the issuer’s MasterCard SecureCode program and obtained a MasterCard
SecureCode to use while shopping online at participating merchants.

The figure below also assumes that all communication channels between the
various components are properly secured using the Secure Socket Layer (SSL)
protocol. See Chapter 6, Component Certificate Requirements for additional
information.

Link Description
SSL-1 The cardholder shops at the merchant and, when ready to checkout,
enters the appropriate payment information—including the account
number.
SSL-2 The Merchant Plug-In queries the Directory to verify the enrollment
status for a specific issuer using the verification request messages. It is
possible that this step will be performed locally at the merchant via the
local MasterCard directory cache, if applicable.

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 2-15
3-D Secure Solution Overview
Cardholder Authentication

Link Description
SSL-3 If the directory indicates that an issuer is participating, then the directory
must forward a request to the issuer’s Access Control Server to check the
enrollment status of a specific cardholder. The configuration information
in the Directory will indicate exactly which Access Control Server will
perform the check. The resulting response will flow back over the same
links to the Merchant Plug-In.

SSL-4 If the Access Control Server indicates that a specific cardholder is

participating, the Merchant Plug-In creates the Payer Authentication
Request message and sends it to the cardholder’s browser.
SSL-5 The cardholder browser redirects the message to the appropriate Access
Control Server to perform cardholder authentication. When the Access
Control Server receives the Payer Authentication Request message, it
causes the user authentication dialog to begin. This in turn causes a
separate authentication window to appear to the cardholder that will
facilitate the cardholder authentication process.

SSL-6 The Access Control Server authenticates the cardholder SecureCode,

constructs the SPA AAV for MasterCard’s implementation of 3-D Secure,
and builds and digitally signs the Payer Authentication Response message.
It is returned to the Merchant Plug-In, at which point the cardholder
authentication window will disappear.

After cardholder authentication is complete, the merchant is required to pass

the corresponding SPA AAV to the acquirer via the UCAF field within the
authorization message. This value is then passed from the acquirer to the issuer
as part of the authorization message.

When received by the issuer, the AAV can be validated as part of authorization
request processing, as well as archived for use in potential cardholder disputes.

©2005–2011 MasterCard. Proprietary. All rights reserved.

2-16 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
Chapter 3 Cardholders
This chapter provides an overview of the various activities and requirements for building and
maintaining the cardholder components that are required to support MasterCard® SecureCode™.

Overview ....................................................................................................................................... 3-1

Infrastructure.................................................................................................................................. 3-1
Availability of Secure Browser ................................................................................................. 3-1

Customization ................................................................................................................................ 3-1

Operational .................................................................................................................................... 3-1

Cardholder Registration ........................................................................................................... 3-1
Use of Pop-Up Blocking Software ........................................................................................... 3-2

Accountholder Authentication Value Processing............................................................................ 3-2

Global Infrastructure Testing Requirements................................................................................... 3-2

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 3-i
 Cardholders
Overview

Overview
This chapter outlines the major activities and requirements for building
and maintaining the cardholder components that are required to support
MasterCard® SecureCode™.

The activities and requirements are separated into five primary categories:
• Infrastructure—Installation of new hardware and software components.
• Customization—Customizing or configuring vendor products.
• Operational—Operating the components in a production environment,
including any process oriented changes that may be required.
• Accountholder Authentication Value (AAV) Processing—Handling and
processing of the AAV.
• Global Infrastructure Testing Requirements—Testing of MasterCard
SecureCode platform components with the MasterCard SecureCode global
infrastructure.

Infrastructure
Following is the cardholder infrastructure requirement for the installation of
new hardware and software components that support MasterCard SecureCode.

Availability of Secure Browser

MasterCard recommends that cardholders have a Web browser that is capable
of supporting 128bit Secure Sockets Layer (SSL) encryption.

Customization
There are no customization issues related to cardholder participation in
MasterCard SecureCode program.

Operational
Following are the cardholder requirements for operating the components in
a production environment, including any process-oriented changes that may
be required.

Cardholder Registration
Depending on the exact nature of a card issuer's program, cardholders may be
asked to register with their issuer to participate in its MasterCard SecureCode
program. Issuers have the option of allowing cardholders to enroll in the
program while shopping at a participating merchant or outside of this process
all together. The exact method of registration will be both issuer and issuer
platform specific.

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 3-1
Cardholders
Accountholder Authentication Value Processing

For accounts with more than one authorized user (for example, husband
and wife), both users should be able to register and create their own unique
SecureCode. After one of the authorized card users has registered, all online
payments using that card—at participating merchants—will cause the cardholder
authentication process to initiate. This process will initiate even if the buyer is
not the cardholder that explicitly enrolled in the program.

Use of Pop-Up Blocking Software

Early merchant implementations of MasterCard SecureCode used pop-up
authentication windows. Pop-up blocking software used by cardholders
inhibited these types of authentication windows from working properly.
MasterCard requires that all merchant implementations use inline authentication
windows because they are not impacted by the use of pop-up blocking
software.
DEFINITION
Pop-up blocking software prevents most types of advertisement windows from being created or
“popping up” while a user browses Web sites.

Accountholder Authentication Value Processing

There are no issues related to processing of the SPA Accountholder
Authentication Value (AAV) for cardholders.

Global Infrastructure Testing Requirements

There are no testing requirements for cardholders.

©2005–2011 MasterCard. Proprietary. All rights reserved.

3-2 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
Chapter 4 Customer Interface Requirements
This chapter helps member personnel understand the MasterCard® SecureCode™ program
requirements associated with issuer purchase authentication and enrollment pages, and details
cardholder enrollment options.

Purchase Authentication Page........................................................................................................ 4-1

General Program Requirements ............................................................................................... 4-1

Cardholder Standard Enrollment.................................................................................................... 4-3

Overall Registration Process .................................................................................................... 4-3
Welcome/Registration Landing Page........................................................................................ 4-5
Congratulations/Successful Registration Page .......................................................................... 4-5
Communication........................................................................................................................ 4-5

Activation During Shopping Enrollment ........................................................................................ 4-6

Benefits.................................................................................................................................... 4-7
General Requirements ............................................................................................................. 4-7
Cardholder Termination of ADS .............................................................................................. 4-9
Issuer-Mandated ADS Enrollment Requirements...................................................................... 4-9

Required Access Control Processing .............................................................................................. 4-9

Required Access Control Server Processing ................................................................................. 4-11

Best Practices ............................................................................................................................... 4-12

Program Awareness ............................................................................................................... 4-12
Communication...................................................................................................................... 4-12
Direct Enrollment Screens...................................................................................................... 4-12
ADS Screens........................................................................................................................... 4-13

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 4-i
 Customer Interface Requirements
Purchase Authentication Page

Purchase Authentication Page

This section describes the function and requirements of the Purchase
Authentication page.

General Program Requirements

A purchase authentication page is presented to enrolled and activated
cardholders when completing an online purchase at a participating MasterCard®
SecureCode™ merchant. MasterCard has defined specific display requirements
and approaches for how this page must be constructed as described in the
following section.

The following requirements must be implemented on all purchase authentication

pages by MasterCard issuers:
1. The payer authentication page must comply with the size and attribute
requirements defined within this guide:
a. Merchants: Minimum of 400 pixels high x 400 pixels wide
b. Issuers: Maximum of 390 pixels high x 400 pixels wide
MasterCard requires that all merchants implement the payer authentication
page as an inline window. Pop-up windows are not permitted for new
merchant implementations.
2. The purchase authentication page must display the SecureCode logo in
the upper left or upper right corner.
3. The purchase authentication page also must display the issuer name or logo
in the upper corner opposite from the SecureCode Program Identifier. Third
party names or logos are not permitted. However, co-branded and affinity
programs should display the same logos as on their cards.
4. Animated logos must not be used.

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 4-1
Customer Interface Requirements
Purchase Authentication Page

5. The minimum acceptable pixel size, both for the SecureCode Program
Identifier and the issuer logo, is 62w x 34h. It is recommended that the
issuer logo be at least as large as the SecureCode Program Identifier. The
issuer logo may be larger than the SecureCode Program Identifier, however
the total area designated for use by both logos must never exceed one-sixth
of the total page area.
6. The minimum acceptable font size is nine.
7. The purchase authentication page must display the required purchase
transaction data carried in the Payer Authentication Request (PAReq)
message as defined in the 3-D Secure specification. This required data
include:

PAReq Field Name (if Display Name Formatting

applicable) Requirements

Merchant Name Merchant

Purchase Amount Amount Must be displayed in the
currency indicated in the
PAReq message
Purchase Date Date The contents of this
field may be optionally
followed by a time zone
designation.
Personal Assurance Personal Greeting Dual issuers may use
Message “Personal Message”
as an alternative to
accommodate both
MasterCard and Visa
program rollouts
Personal Account Card Number The card number must
Number be masked to display
only the last 4 digits
8. The purchase authentication page also must display:
a. SecureCode entry box—The preferred display name is “SecureCode,”
although “SecureCode Password” is permitted. If the cardholder’s
SecureCode is a pre-existing password already established with the
issuer (for example, an online banking password), the issuer may submit
a waiver request to MasterCard when submitting its screens for approval.
b. SecureCode recovery mechanism. MasterCard recommends the
terminology used for the recovery mechanism be synchronized with the
display name of the SecureCode entry box (“Forgot SecureCode” or
“Forgot SecureCode password”).
c. Submit button to submit the SecureCode to the issuer for verification
d. Help link
e. Cancel button
9. The purchase authentication page must not contain any competing payment
scheme logos or authentication solution program identifiers.

©2005–2011 MasterCard. Proprietary. All rights reserved.

4-2 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 Customer Interface Requirements
Cardholder Standard Enrollment

10. The purchase authentication page must not contain any external links
or be used for any purpose other than authentication. For example, the
page must not be used for promotions, advertising, or other marketing
communications.
11. The purchase authentication page must contain the text “This information
is not shared with the merchant.”
12. If a user ID is used in addition to SecureCode values for authentication
purposes, the user ID must be pre-populated on the purchase authentication
page to minimize cardholder confusion and data entry requirements.
13. A fallback mechanism must be supported in cases where Java script is either
disabled or unavailable at the cardholder’s browser.
14. All uses of the term SecureCode™ must be in English.
15. No scroll bars are permitted.

Cardholder Standard Enrollment

Standard enrollment of a targeted card base takes place completely outside of
the shopping experience. It is initiated by an issuer communication to the target
market through one or more traditional marketing communication channels.
This may include e-mail, statement messages or inserts, direct mail, or banner
ads or links from the issuer’s Web site or online banking service. Regardless
of the communication method, consumers that are interested in enrolling will
be directed to the issuer’s SecureCode enrollment Web site or to an issuer’s
customer service representative. There they will be prompted for their card
numbers and other enrollment-specific, shared secrets that exist between each
cardholder and issuer for identity verification purposes. A successful identity
verification will result in the cardholder being allowed to establish his or her
SecureCode.

It is becoming increasingly popular for issuers to have a SecureCode solution

that is tightly integrated with their online banking service. In these cases,
standard enrollment may be performed from within the online banking site with
the cardholder using his or her online banking password as the SecureCode.

In addition to enrollment activities, the issuer’s SecureCode enrollment Web

site also typically may contain an account management section where a
cardholder can change his or her SecureCode and view transactions in his or
her SecureCode transaction history.

Overall Registration Process

Requirements include:
• The enrollment pages must not contain any competing payment scheme
logos or authentication solution program identifiers.

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 4-3
Customer Interface Requirements
Cardholder Standard Enrollment

• Issuers must display their name, logo, or both, as well as the SecureCode
program identifier, on all enrollment pages to assure their cardholders that
their registrations are being processed by a trusted party. All enrollment
pages must adhere to the Program Identifier Usage Guidelines accessed
using the following Web address: www.mastercard.com/us/merchant/secu-
rity/what_can_do/pdf/SecureCode_logo_usage.pdf.
• On all enrollment pages, the minimum acceptable pixel size, both for
the SecureCode program identifier and the issuer logo, is 120w x 65h.
MasterCard recommends that the issuer logo be at least as large as the
SecureCode program identifier. The issuer logo may be larger than the
SecureCode program identifier, however the total area designated for use by
both logos must never exceed one-sixth of the total page area.
NOTE
The above requirement differs from those for the authentication page logo.

• The enrollment pages must not be used for non-enrollment purposes such
as promotions, advertising, or other marketing communications, unless the
promotion is directly related to program enrollment or usage at participating
merchants.
• Issuers must establish a Personal Greeting for all cardholders, either by
soliciting cardholders to provide their own Personal Greetings at the time
of enrollment or by assigning a unique or common Personal Greeting to
all enrolled cardholders. Personal Greetings assigned by an issuer must
not contain cardholder account numbers, SecureCode values, or other
private information. Dual issuers that are deploying 3-D Secure for both
MasterCard and Visa are permitted to use the term “Personal Message” as an
alternative to “Personal Greeting.”
• Issuers must provide a method for resetting a forgotten SecureCode.
MasterCard recommends prompting cardholders to answer the same shared
secret questions asked during enrollment. Other examples include:
– Provide a Secret Question and Answer process. This is where the
cardholder defines a question and associated answer. The question
can be either determined by the cardholder or selected from an issuer
provided list.
– Provide an authentication process conducted via phone by a customer
service representative. MasterCard recommends re-authentication over
other methods because it is more secure, easier for the cardholder,
and less expensive for the issuer.
• Issuers must ensure cardholders have access to the issuer’s relevant terms
and conditions and privacy policy before cardholders are asked to enroll
and/or activate. Additionally, if legally required, issuers must ensure
cardholder acceptance of these terms, conditions, and policies.

©2005–2011 MasterCard. Proprietary. All rights reserved.

4-4 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 Customer Interface Requirements
Cardholder Standard Enrollment

• Issuers should carefully consider the selection of authentication data and

should understand consumer reaction to providing sensitive personal
information such as a full social security number. MasterCard recommends
requesting abbreviated information for sensitive data—such as the last four
digits of the social security number. As a best practice for authentication, and
to facilitate completion of the registration process, MasterCard recommends
that issuer’s use data that are easily accessible to the cardholder. For
example, requesting information from the cardholder’s bank statement or
requesting a code that was previously mailed to the cardholder requires
the cardholder to halt the registration process and look for the necessary
document, which the cardholder may or may not have saved.
• As a best practice, MasterCard recommends that a SecureCode be a
minimum of six characters and contain at least one number and one letter.
Use of ATM PINs is strongly discouraged.

Welcome/Registration Landing Page

Requirements include:
• The welcome page should explain clearly the MasterCard SecureCode
program and offer cardholders the opportunity to watch a demonstration
(available from MasterCard at no cost).
The welcome page should provide a link to:
– a current list of participating merchants
– frequently asked questions (http://www.mastercard.us/sup-
port/securecode.html)
– Contact Us (Issuer support)
• The enrollment pages must not contain any competing payment scheme
logos or authentication solution program identifiers.

Congratulations/Successful Registration Page

Issuers should remind users that the service works automatically at participating
merchants and that no login is required.

Communication
Requirements include:
• Issuers should remind the cardholder that MasterCard SecureCode is an
enhancement to their existing MasterCard® card or Maestro® card and that
applying for a new card is not necessary.
• If issuers will not be charging cardholders for the SecureCode service, they
should mention this prominently on the welcome page.

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 4-5
Customer Interface Requirements
Activation During Shopping Enrollment

Activation During Shopping Enrollment

Activation During Shopping (ADS) is a proactive approach to cardholder
enrollment. Unlike standard enrollment processes, which require that the
cardholder take initiative to enroll in the program, ADS permits the issuer to
solicit cardholder enrollment as part of the shopping experience. This approach
also provides issuers with a means for requiring cardholder participation, if
desired.

Cardholder response rates to ADS have been higher than those associated with
standard enrollment, when issuers have sufficiently communicated SecureCode
program details and benefits to their cardholder base. While effective in driving
program enrollment, issuers must take care to minimize any disruption to
purchase completion and avoid negative impact to participating merchants.

In recognition of this, MasterCard has outlined the requirements in this

document with three goals in mind:
• Maximize cardholder registrations
ADS has proven to be very effective when deployed correctly. Several
issuers have attained very high rates of registration with ADS.
• Minimize loss of volume
If not orchestrated correctly, ADS could cause some cardholder
dissatisfaction. This may result in loss of purchase volume for the issuer.
• Minimize lost merchant sales
If merchants perceive that consumers are spending excessive time during
the checkout process, they are likely to have concerns about the SecureCode
program.

Early use of ADS caused some concern within the merchant community
regarding the potential for disruption of the sales process in some issuer
deployments. Such concerns included the consumer abnormally terminating the
registration, thereby causing abandonment of the entire purchase transaction.

Problems that occurred can be traced to a handful of causes that can be easily
avoided:
• Lack of consumer education
• Lack of proper financial institution and program identifiers
Registration windows must clearly identify the consumer’s financial
institution to avoid confusion and fear of spoofing or “phishing” scams.
• Overly long registration process
Once presented, the registration should be short and straightforward. The
use of too many questions to establish the identity of cardholders will only
tax their patience and cause them to abandon the process.

Each issuer is responsible for evaluating the pros and cons of ADS enrollment
in general, as well as the individual methods for initiating ADS, to determine
which course of action is most appropriate for its program. However, the
requirements and guidelines outlined below are based on issuer experiences as
well as on extensive focus groups and usability studies, so issuers may want to
leverage these learnings for their own SecureCode deployments.

©2005–2011 MasterCard. Proprietary. All rights reserved.

4-6 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 Customer Interface Requirements
Activation During Shopping Enrollment

Benefits
ADS enrollment benefits issuers directly by providing a low cost, yet effective,
means for mass enablement of cardholders that shop at participating SecureCode
merchants. Issuers can leverage the growing population of SecureCode enabled
merchants as points of enablement for their programs. When complemented
with cardholder communication programs via traditional channels such as
e-mail, statement messages, statement inserts, and direct mail, ADS can result
in significantly higher consumer uptake than traditional enrollment methods.
MasterCard requires that any issuer using ADS maintain a standard enrollment
site containing detailed program information, and that issuers using ADS comply
with the following communication requirements.

General Requirements
Requirements include:
• Issuers must provide enrollment program details for SecureCode ADS to
MasterCard no later than 30 days before the planned program initiation
date. These communications must alert cardholders that they may receive
a SecureCode enrollment request box from their issuer while shopping
online. MasterCard must approve the following issuer program details
before implementation can commence:
– Screen shots of the cardholder graphical user interface at the time of
functional testing
– Cardholder communication plans, including the issuer’s SecureCode
Web site URL, and copies of communications pieces including any
statement inserts, statement messages, or direct mail pieces
– ADS program rollout schedule
– E-mail notifications, if feasible
• Issuers that want to launch an ADS enrollment program must initiate the
following cardholder communications:
– Statement messaging—statement messaging must begin at least 30 days
before the program launch and must continue for at least two months.
– Notification on issuer Web site(s)—in addition to describing
consumer program benefits, the issuer also may provide a link to
www.mastercard.us/securecode.html for details pertaining to the overall
MasterCard SecureCode program.
• Issuers must display their name, logo, or both, on all ADS enrollment and
authentication pages to assure their cardholders that a trusted party is
processing their transactions.
• All ADS enrollment pages must include the SecureCode program identifier
logo and must adhere to the program usage guidelines.
• The minimum acceptable pixel size, both for the SecureCode program
identifier and the issuer logo, is 62w x 34h. MasterCard recommends that
the issuer logo be at least as large as the SecureCode program identifier.
The issuer logo may be larger than the SecureCode program identifier, but
in no case may the total area taken up by both logos exceed one-sixth
of the total page area.
• The minimum acceptable font size is nine.

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 4-7
Customer Interface Requirements
Activation During Shopping Enrollment

• Issuers are limited to two pages for ADS enrollment exposure, including
the enrollment and authentication pages. Page sizes must adhere to the
guidelines outlined in this chapter:
a. Merchants: Minimum of 400 pixels high x 400 pixels wide
b. Issuers: Maximum of 390 pixels high x 400 pixels wide
In addition, issuers should restrict the size of text, source code, and graphics
to enhance transaction processing speed.
• Issuer authentication pages must not resize the merchant-created
authentication page window. While this causes no real impact with the use
of pop-up windows, it does cause merchant Web site presentation problems
with the use of inline windows.
• Issuers must not ask cardholders to establish a SecureCode hint during ADS
enrollment. Issuers may pre-assign unique or standard SecureCode hints
for their card bases.
• Pending MasterCard approval, issuers may ask cardholders to establish a
Personal Greeting during ADS enrollment.
• Dual issuers that are deploying 3-D Secure for both MasterCard and Visa are
permitted to use the term “Personal Message” as an alternative to Personal
Greeting.
• Issuers must ensure cardholders have access to the issuer’s relevant terms
and conditions and privacy policy before cardholders are asked to enroll or
activate. Additionally, if legally required, issuers must ensure cardholder
acceptance of these terms, conditions, and policies.
• Direct links to items other than terms and conditions or a privacy policy
are permitted if such links are critical to achieving a successful activation.
Acceptable linked windows include an explanatory diagram of the
“signature panel code” or a program explanation. Such links must be
for content resident at the ACS as no external links are permitted due to
impacts to processing time.
• ADS may be used only for SecureCode enrollment of MasterCard or Maestro
accounts. It must not be used as a channel for promotions or advertising.
• The standard enrollment site URL may be included only as text and not as
an active link, to minimize interruptions in the purchasing process.
• A pop-under program announcement is permitted as an informational piece
following a successful enrollment or, optionally, if a cardholder chooses
to delay enrollment.
• In consideration of ADS enrollment occurring during the online buying
session, issuers should consider carefully the selection of authentication
data and understand consumer reaction to providing sensitive personal
information such as a full social security number. MasterCard recommends
requesting abbreviated information for sensitive data, such as the last four
digits of the social security number. As a best practice, MasterCard also
recommends no more than four data items be used for authentication and
that data items selected are readily accessible to the cardholder to facilitate
completion of the registration.
• As a best practice, MasterCard recommends that a SecureCode be a
minimum of six characters and contain at least one number and one letter.
Use of ATM PINs is strongly discouraged.

©2005–2011 MasterCard. Proprietary. All rights reserved.

4-8 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 Customer Interface Requirements
Required Access Control Processing

• E-mail addresses may be collected at the time of enrollment from all

cardholders. Issuers should provide an e-mail cardholder notification of all
successful activations.
• When using a pre-assigned SecureCode, issuers may choose to use an
existing password, for example, an online banking password.

Cardholder Termination of ADS

If the cardholder chooses to close the enrollment window, the issuer ACS must
present a browser alert message to the cardholder. This alert message will
inform the cardholder that the SecureCode authentication has not yet completed.
If the cardholder responds to this alert by clicking on OK, an authentication
failed page is displayed to the cardholder. If instead, the cardholder selects
Cancel, the issuer once again displays the current SecureCode enrollment
activation page.

Issuer-Mandated ADS Enrollment Requirements

In some cases, issuers have decided to mandate cardholder participation in their
MasterCard SecureCode program. This requires that all cardholders shopping
online must enroll in their issuer’s SecureCode program.

As a best practice, MasterCard encourages issuers to allow cardholders the

ability to opt out at least three times before presenting an activation page that
requires the cardholder to enroll.

In addition to the other requirements in this document, issuers that mandate

cardholder participation must adhere to the following requirements:
• Issuers that require cardholder participation may present an ADS enrollment
page that solicits activation either by requiring the cardholder to create their
own SecureCode or by entering an issuer pre-assigned SecureCode.
• Issuers who force cardholders to enroll in SecureCode through some method
other than ADS (for example, automatically enrolling their entire online
banking base) must follow the same approval process outlined in General
Requirements and must adhere to the best practice recommended above.

Required Access Control Processing

The following diagram is intended to provide a high level sample flow of the
MasterCard ADS enrollment requirements. Additional processing items such as
number of authentication attempts before failure or lockout, and number of
consecutive cardholder declined solicitations may be configured by the issuer.

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 4-9
Customer Interface Requirements
Required Access Control Processing

Figure 4.1—Sample Processing Flow

The issuer Access Control Server (ACS) receives a Payer Authentication Request
(PAReq) message requesting authentication of the specified cardholder. The
ACS, recognizing that the cardholder is not currently enrolled in the program
but belongs to a qualifying card range selected by the issuer, provides the
cardholder with the requisite information, determined by the type of ADS being
performed. See Required Access Control Server Processing in this chapter for
additional information.

Permitted options on this display include:

• Cardholder may view:
– Issuer’s program terms and conditions
– Issuer’s privacy policy
– Sample signature panel or other necessary direct links
• If the cardholder chooses not to enroll, assuming there is no mandatory
enrollment policy, the issuer may leave behind a follow-up message via a
pop-under browser window.
DEFINITION
On the Web, a pop-under is a window that is created but temporarily "hidden" behind the window
of a Web site that the user has chosen to visit. When the visitor leaves the site that was being
visited, the pop-under window becomes visible.

If the cardholder provides the appropriate authentication data and agrees to

accept the program terms, the cardholder is presented with another page
containing data requisite to the type of ADS being performed. Refer to Best
Practices in this chapter for additional information.

The cardholder has successfully been authenticated and activated for the
issuer’s SecureCode program.

©2005–2011 MasterCard. Proprietary. All rights reserved.

4-10 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 Customer Interface Requirements
Required Access Control Server Processing

Permitted options from this point include a pop-under window with a

cardholder enrollment acknowledgement. This window may contain an
enrollment acknowledgement message and a hyperlink to the issuer’s program
welcome page.

Required Access Control Server Processing

Some data within the PARes message returned by the ACS to the merchant will
vary depending upon the cardholder reaction to the solicitation.

PARes
Transac- AAV
tion Sta- Control AAV Authentication
Description tus Byte Method
The cardholder is successfully Y x8C Any non-zero value as
authenticated and enrolled in defined in the Secure
SecureCode. Payment Application
(SPA) Algorithm
for the MasterCard
Implementation of 3-D
Secure
The cardholder attempted N N/A N/A
to authenticate but was not
successful.
The cardholder decides not to A x88 0
enroll in the program at the
current time
The cardholder is successfully A x88 0
authenticated but chooses not
to complete the process (this
includes selecting to “X” out of
enrollment).

The issuer ACS must follow the procedures for generating a Secure Payment
Application (SPA) Accountholder Authentication Value (AAV). These procedures
are defined by MasterCard for “Attempts” processing using the SPA Algorithm
for MasterCard Implementation of 3-D Secure. In addition to proper setting
of the control byte, MasterCard requires the Authentication Method field
within the SPA AAV to be set to 0 when the Transaction Status field in the
PARes message is set to A. Use of an Attempts designation in support of ADS
cardholder enrollment deferment or decline does not imply broader support of
Attempts processing by MasterCard.

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 4-11
Customer Interface Requirements
Best Practices

The AAV that is created for a transaction status of “A” (attempt) is not
based on an actual cardholder authentication. Per the existing MasterCard
implementation requirements, SecureCode-enabled merchants must not include
an AAV associated with a PARes message with an Authentication Status of “A”
and an AAV control byte of x86 to be passed with the authorization request
to the acquirer. Such transactions do not qualify as authenticated transactions
and would not benefit from liability shifts associated with MasterCard rules
for fully authenticated transactions.

Best Practices
In addition to the requirements outlined in the previous sections, MasterCard
has compiled the following list of recommended best practices.

Program Awareness
Issuers should give cardholders several chances to enroll, as repeated exposure
will build familiarity. Alternatively, a mandate can be used quite effectively but
should follow an opt-in period to minimize negative reaction.

If the consumer chooses not to activate, his or her e-mail address may be
captured so information about the program can be sent to the consumer for
future consideration.

Communication
Use low-key language to communicate the benefit of SecureCode, for example,
“even more secure … an extra level of security.”

Avoid words like “enroll” or “pre-enrolled” or “pre-approved” that trigger

negative associations with other service offers.

“Free” programs should be communicated prominently and in several locations,

given consumer skepticism about so-called free offers.

Be clear about how SecureCode works. For example, state: “If someone doesn’t
know your code they can’t use your card.”

If an e-mail address is collected, reassure the consumer that it will not be sold
to or shared with any third parties.

Cardholders should be reminded to disable any software that prevents pop-ups,

as this will interfere with the use of SecureCode.

Direct Enrollment Screens

Explain in simple language how the program works. For example, use the
analogy of using one’s PIN at an ATM to establish familiarity.

©2005–2011 MasterCard. Proprietary. All rights reserved.

4-12 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 Customer Interface Requirements
Best Practices

Provide a demonstration of enrollment and purchasing.

If the service is free, mention it prominently in several locations.

Once cardholders are enrolled, remind them that program login is not
necessary. (The lack of login confused cardholders who expected to “initiate”
the SecureCode purchase process when needed.)

Remind enrollees to bookmark the account management page because there

is no desktop icon to access.

Many consumers preferred the phrase “Personal Greeting” over “Personal

Message” when registering. Some were confused about the latter term and
thought it would be another phrase to memorize, similar to a secret question
and answer. “Personal Greeting” better communicated the intent.

ADS Screens
Feature the Program Terms link prominently on the first screen as many
consumers expressed interest in reviewing the terms before committing to the
program. When the link is clicked, the Program Terms should appear in a
smaller window.

Limit the number of security questions required to two or three. (Four appeared
to be troublesome.) Do not ask for the cardholder’s entire social security
number, as many consumers are wary of putting this information online. Be
sure the information being asked is on file, accurate, and complete, so that
eligible cardholders avoid unnecessary failures and frustration.

Do not require an exact match on all security questions. Frequently, cardholder

information that issuers have on file may be out of date (for example, home
phone number), missing (for example, e-mail address), or contain data entry
errors (for example, mother’s maiden name). However, issuers may be unaware
of these inaccuracies until cardholders begin failing authentication in great
numbers because the issuer has decided to require a 100% match or case
sensitivity.

Create a clear distinction between the identity verification step and the step
in which the SecureCode is created.

Issuers should be aware of which pieces of data cardholders are sensitive about
sharing because requesting a “sensitive” piece of data will depress response
rates. (For example, cardholders may be willing to provide the last four digits
of their social security number, but not the entire number.)

Where possible, one of the screens should include the exact URL where
program details can be found so that the cardholder does not have to search
through the issuer’s entire site to find the SecureCode section.

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 4-13
Chapter 5 Issuers
This chapter provides an overview of the activities and requirements for building and maintaining
the issuer components that are required to support MasterCard® SecureCode™.

Overview ....................................................................................................................................... 5-1

Infrastructure ................................................................................................................................ 5-1

Establishment of SecureCode Operating Environment............................................................. 5-1
Secure Operating Facility .................................................................................................. 5-1
ACS for Cardholder Authentication ................................................................................... 5-1
Cardholder Enrollment Server............................................................................................ 5-2
Digital Signature Key Management.......................................................................................... 5-2
Authorization System Message Enhancements......................................................................... 5-3
Maestro Considerations............................................................................................................ 5-3
Account Number Length Requirements ............................................................................. 5-3
Static Account Number Requirements................................................................................ 5-3
Track 2 Requirements ........................................................................................................ 5-3
MDS Support ..................................................................................................................... 5-4
Account in Good Standing................................................................................................. 5-4

Customization ................................................................................................................................ 5-4

Authentication Window Contents ............................................................................................ 5-4
Program Identifier Usage Guidelines ....................................................................................... 5-5
Establishment of Cardholder Enrollment Process .................................................................... 5-5

Operational .................................................................................................................................... 5-6

MasterCard SecureCode Directory Server Maintenance............................................................ 5-6
SSL and Digital Signing Certificates.......................................................................................... 5-6
Customer Service ..................................................................................................................... 5-6
Authentication History Server ................................................................................................. 5-7

Accountholder Authentication Value (AAV) Processing ................................................................ 5-7

SPA AAV Algorithm .................................................................................................................. 5-7
Electronic Commerce Indicator................................................................................................ 5-7
AAV Validation and the AAV Validation Service ....................................................................... 5-8

Global Infrastructure Testing Requirements................................................................................... 5-8

MasterCard SecureCode Toolkit ..................................................................................................... 5-9

SecureCode 360 Webinar Series ..................................................................................................... 5-9

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 5-i
Issuers

MasterCard SecureCode Hosted ACS Service ................................................................................. 5-9

©2005–2011 MasterCard. Proprietary. All rights reserved.

5-ii 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 Issuers
Overview

Overview
This chapter outlines the major activities and requirements for building and
maintaining the issuer components that are required to support MasterCard®
SecureCode™.

The activities and requirements are separated into five primary categories:
• Infrastructure—Installation of new hardware and software components.
• Customization—Customizing or configuring vendor products.
• Operational—Operating the components in a production environment,
including any process oriented changes that may be required.
• Accountholder Authentication Value (AAV) Processing—Handling and
processing of the AAV.
• Global Infrastructure Testing Requirements—Testing of MasterCard
SecureCode platform components with the MasterCard SecureCode global
infrastructure.

Infrastructure
Following are the requirements related to the installation of new hardware and
software components.

Establishment of SecureCode Operating Environment

Following is information about establishing the MasterCard SecureCode
operating environment for issuers.

Secure Operating Facility

Issuers must establish a secure operational facility for performing cardholder
authentication processing and AAV generation. All facilities must adhere
to MasterCard security requirements regarding operations of cardholder
authentication processing platforms. For more information, refer to the
SecureCode ACS Security Requirements.

ACS for Cardholder Authentication

Issuers must implement a secure access control server (ACS) for
cardholder authentication. All vendor software used for cardholder
authentication must be at least 3-D Secure v1.0.2 and MasterCard
SecureCode compliant. For a list of compliant vendor software, refer to:
www.mastercardmerchant.com/securecode/vendors.html.

In the case of a successful cardholder authentication, the ACS will create an AAV.
In the case of a chargeback or other potential dispute processing, the AAV will
be used to identify the processing parameters associated with the transaction.

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 5-1
Issuers
Infrastructure

MasterCard has defined several key fields within the AAV structures that will
identify, among other things:
• The ACS, which created the AAV.
• The sequence number that can be used to positively identify the transaction
within the universe of transactions for that location.
• The secret key used to create the message authentication code (MAC),
which not only ensures AAV data integrity but also binds the entire AAV
structure to a specific PAN.

The following field dependencies have been established and must be considered
when building a cardholder authentication installation. To begin, each
cardholder authentication facility will have a numeric identifier assigned to it.

AAV Field Name Dependency

ACS Identifier If one facility serves multiple issuers, more than one
issuer may share a facility ID. In these cases, the BIN
for the associated transaction becomes the delineating
factor for interpreting the field content location.

For each cardholder authentication facility with the same facility ID:

AAV Field Name Dependency

BIN Key Identifier A unique numeric value identifying the cryptographic
key used to create the MAC.
Transaction Sequence A unique numeric field used to identify a specific,
Number successful cardholder authentication request. At a
minimum, this field must be unique during the time a
chargeback could occur.

Cardholder Enrollment Server

Issuers must implement a secure server and process for the purpose of enrolling
cardholders in the MasterCard SecureCode program. The exact method for
performing cardholder enrollment is to be decided by the issuer. In some
cases, the ACS may provide the dual purpose of cardholder enrollment
and authentication. For more information, please refer to Establishment of
Cardholder Enrollment Process in this chapter.

Digital Signature Key Management

Issuers must securely create and manage the keys to be used for performing
digital signing of cardholder authentication requests, as well as keys used to
generate the message authentication code component of the AAV. MasterCard
requires that all key management activity associated with the Access Control
Server be performed through a FIPS140-2 (minimum) hardware security module.

©2005–2011 MasterCard. Proprietary. All rights reserved.

5-2 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 Issuers
Infrastructure

ACS hosting providers and processors must have the ability to utilize a separate
digital signature key and associated MasterCard hierarchy certificate for each
issuer.

ACS hosting providers and processors must have the ability to use a separate
secret key for each individual issuer.

Authorization System Message Enhancements

Issuers must adhere to Universal Cardholder Authentication Field (UCAF)
compliance requirements as outlined in Chapter 1, Overview. Among other
things, this includes support for the UCAF and Security Level Indicator in DE
48, subelement 42 and subelement 43.

Maestro Considerations
The following requirements and activities are specific to issuer support of
Maestro® cards as part of the MasterCard SecureCode program.

Account Number Length Requirements

Maestro requires that issuers provide cardholders who wish to participate in
ecommerce an account number that is 13–19 digits in length.

Static Account Number Requirements

In order to both facilitate higher levels of customer service and provide
increased security, Maestro requires that all Internet transactions be performed
using a static account number. This is a number that may differ from the
real account number, yet stay the same for all Internet purchases made by
the cardholder.

Track 2 Requirements
If the issuer’s authorization system requires track 2 data, the issuer will need
to implement a platform that can intercept the message prior to authorization
and create real track 2 data. Technology vendors, which implement surrogate
account number solutions, are good candidates for these platforms. Currently,
Maestro authorization networks will add pseudo Track 2 data in the following
format:

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 5-3
Issuers
Customization

No Field Name Length Value

1 PAN n…19 PAN as supplied in authorization message.
Currently, issuers are required to issue 16
digit account numbers for Maestro Internet
use. However, acquirers are requested to
implement this functionality based on an
account number of 12–19 digits in length.
2 Separator ans-1 ‘D’
3 Expiry Date ans-4 Expiry Date (YYMM) as supplied in
authorization message.

4 Service Code ans-3 ‘101’

For more information, please refer to the appropriate authorization specification

manual.

MDS Support
Maestro is supported on the Single Message System in regions outside of the
Europe region. Issuers are required to reference the appropriate authorization
specification manual for messaging details.

Account in Good Standing

Maestro requires that all issuers provide support for Account in Good Standing
transactions. For more information, see Appendix D, Maestro Considerations.

Customization
The following is MasterCard SecureCode customization information for issuers.

Authentication Window Contents

The 3-D Secure protocol is designed so that creation of the cardholder
authentication window is performed by the merchant. The issuer controls the
actual content of the window. All cardholder authentication pages must adhere
to published MasterCard requirements on this topic. For more information,
see Chapter 4, Customer Interface Requirements. Proof of adherence to the
MasterCard requirements is a condition of successful completion of SecureCode
issuer functional testing. MasterCard highly recommends that all screenshots be
provided for review as soon as possible in case changes are required.

MasterCard recommends that all issuers ensure that the content of their
cardholder facing screens adhere to all parameters related to regional or country
specific disability requirements as defined by the applicable law.

©2005–2011 MasterCard. Proprietary. All rights reserved.

5-4 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 Issuers
Customization

Issuers should be aware that not all cardholder browsers can support JavaScript.
Issuer screens must be able to function properly in the event that the
cardholder’s browser has JavaScript enabled.

Program Identifier Usage Guidelines

Issuers must adhere to the applicable usage guidelines as indicated in
the MasterCard SecureCode Program Identifier Guidelines accessed using
the following Web address: www.mastercard.com/us/merchant/secu-
rity/what_can_do/pdf/SecureCode_logo_usage.pdf. Proof of adherence to
these guidelines must be provided to MasterCard as a condition of successful
completion of SecureCode issuer functional testing. MasterCard highly
recommends that all screenshots be provided for review as soon as possible
in case changes are required.

A copy of the MasterCard SecureCode logo artwork is available for download at

www.mastercardmerchant.com/securecode/artwork.html.

Establishment of Cardholder Enrollment Process

Issuers have multiple options for soliciting cardholder participation in their
MasterCard SecureCode program:
• Direct Enrollment—Provides a general enrollment site where cardholders
are solicited to enroll via traditional marketing communications including
e-mail, statement messages, statement inserts, and direct mail.
• Activation During Shopping—Solicits enrollment during the shopping
process. This proactive approach to enrollment has proven to be very
effective at getting cardholders to enroll in the program. If desired, it is also
used by many issuers as a means to require cardholder participation.
• Forced Enrollment—Provides a way for issuers to “bulk” register a specific
base of cardholders. For example, this may include all home banking
customers.

Regardless of the method chosen by issuers, following are some basic planning
decisions that must be made:
• Method of cardholder enrollment authentication. This could be via existing
systems such as an online banking site or it could relate to answering of
secret questions. In the latter case, MasterCard recommends using multiple
pieces of information to perform the authentication. Examples may include
Address Verification Service (AVS) and Card Validation Code 2 (CVC 2)
checks in combination with various secret questions.
• Definition of secret questions for example, authentication questions, that
must be answered by the cardholder. MasterCard recommends that issuers
ensure that the secret information is verifiable and not all available from a
single source, such as a monthly statement. Examples may include mother’s
maiden name, partial social security number, national ID number, date
of birth, or secret activation code.
• Definition of cardholder terms and conditions.

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 5-5
Issuers
Operational

• Definition of cardholder SecureCode requirements, including the minimum

and maximum size, content (for example numbers, letters, or combinations)
and attempts allowed prior to terminating access. MasterCard strongly
recommends that all SecureCode values be a combination of at least 6–10
letters and numbers. Any use of financial PINS as SecureCode values must
adhere to MasterCard Information Security requirements regarding PIN
and key management.

MasterCard has developed strict requirements regarding the use of the various
cardholder enrollment methods. Proof of adherence to these requirements
must be provided to MasterCard as a condition of successful completion of
SecureCode issuer functional testing. MasterCard highly recommends that all
screenshots be provided for review as soon as possible in case changes are
required.

For more information, see Chapter 4, Customer Interface Requirements.

Operational
Following are details about the operational aspects of issuers implementing
MasterCard SecureCode.

MasterCard SecureCode Directory Server Maintenance

Issuers are responsible for ensuring that MasterCard has the appropriate card
range information and ACS URL for initialization of the MasterCard Directory
server. MasterCard will only accept updates from authorized contact, as
indicated on the program enrollment forms. All updates must be made using
the approved submission form, available from [email protected].

For more information about directory updates and maintenance schedules,

please refer to the MasterCard SecureCode Production Procedures publication.

SSL and Digital Signing Certificates

Issuers are responsible for requesting, installing, and maintaining all necessary
Secure Socket Layer (SSL) server and digital signing certificates for use by the
access control server platform. All MasterCard hierarchy certificates must be
obtained from MasterCard. See Chapter 6, Component Certificate Requirements.

Customer Service
Issuers must assess customer service training and modifications of dispute
resolution procedures to incorporate the Accountholder Authentication Value
(AAV).

©2005–2011 MasterCard. Proprietary. All rights reserved.

5-6 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 Issuers
Accountholder Authentication Value (AAV) Processing

Authentication History Server

Currently, MasterCard does not operate an Authentication History Server, but
may do so sometime in the future. Issuers must ensure that MasterCard®
and Maestro® branded transactions are not forwarded to any other brand
authentication history servers.

Accountholder Authentication Value (AAV) Processing

Following is information about AAV Processing for issuers.

SPA AAV Algorithm

All issuers deploying issuer platforms for MasterCard SecureCode must use
the SPA algorithm for generating the AAV value. The use of this algorithm is
indicated in the PARes message with a value of “3” (MasterCard SPA Algorithm)
in the CAVV algorithm field.

Electronic Commerce Indicator

An e-commerce indicator flag is required to be present in all PARes messages
sent by the issuer ACS to the merchant when the status field contains a value of
Y or A. As currently defined, the 3-D Secure protocol indicates that this ECI
field be determined by each brand. As a result, MasterCard has adopted values
that may be different from other participating payment brands.

MasterCard has currently defined two ECI values. The table below indicates the
relationship between these values and the status field in the PARes message.

PARes
Status MasterCard ECI
Field Description Value
Y Cardholder was successfully authenticated 02
A Authentication could not be completed but a 01
proof of authentication attempt was provided.
NOTE
h vs. j in the control byte.
N Cardholder authentication failed Absent
U Authentication could not be completed due to Absent
technical or other problems

While MasterCard has no corresponding ECI field in the authorization message

formats, the values chosen correspond to the values currently defined for
the UCAF Collection Indicator field in data element (DE) 48 (Additional
Data—Private Use), subelement 42 (Electronic Commerce Indicator), position 3
(UCAF Collection Indicator).

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 5-7
Issuers
Global Infrastructure Testing Requirements

AAV Validation and the AAV Validation Service

MasterCard recommends, but does not require, that issuers validate the SPA AAV
in real-time prior to generating the authorization response. In support of this
activity, MasterCard has made available an “on-behalf-of” SPA AAV validation
service. This service is invoked as transactions flow through the authorization
network and can be configured to perform validation on all transactions or only
during stand-in processing. Enrollment in this service is through MasterCard
OnLine® product registration for product MasterCard SecureCode AAV
Validation Service. Contact your regional Customer Implementation Service
team for more information or to initiate a project.

At a minimum, issuers are required to maintain the SPA AAV and all information
(for example, secret keys) required to perform the validation for the requisite
transaction in the event of a customer chargeback or other dispute involving
the transaction. MasterCard recommends a storage period of at least 180 days.

When validating the SPA AAV, it must first be Base64-decoded. For additional
information about Base64, refer to Appendix A, SecureCode SPA Algorithm
Specifications.

Issuers must be aware that the Attempts processing model, as defined in the
3-D Secure Protocol version 1.0.2, permits the creation of a SPA AAV without
cardholder authentication. At the time of publication, the only approved
use of an attempt response is when the cardholder declines to enroll in the
program as part of Activation During Shopping (ADS). A cardholder could
decline to enroll at either the Identification and Verification or Create Your
SecureCode screens of standard ADS enrollment. Issuers are restricted from
using Attempts processing for any other purposes as part of a MasterCard
SecureCode implementation.

Global Infrastructure Testing Requirements

All issuers are required to complete MasterCard SecureCode issuer functional
testing. The purpose for this testing is to ensure that member-hosted
ACS implementations meet minimum functional and brand requirements
for participating in the MasterCard SecureCode program. Additional
information about the testing process can be obtained by sending a request to
[email protected].

Presently, MasterCard authorization testing is separate and distinct from

MasterCard SecureCode authentication testing. Testing for such system
modifications should be accomplished either by using existing MasterCard
simulators or coordinated through the MasterCard Customer Implementation
Services group.

©2005–2011 MasterCard. Proprietary. All rights reserved.

5-8 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 Issuers
MasterCard SecureCode Toolkit

MasterCard SecureCode Toolkit

To assist issuers in communicating with their cardholders concerning the
MasterCard SecureCode program and its benefits and features, MasterCard has
developed a communications toolkit available via MasterCard OnLine®. The
MasterCard SecureCode Program Toolkit provides issuers with standardized and
customizable cardholder communication materials including statement inserts,
post cards, and more.

Request access to the MasterCard SecureCode Toolkit using either of the

following methods:
• MasterCard SecureCode resource center of MasterCard OnLine.
• mastercard.com—www.mastercard.com/us/merchant/secu-
rity/what_can_do/SecureCode/toolkit/SecureCode.html#Order the
SecureCode Program Toolkit

SecureCode 360 Webinar Series

MasterCard has created a series of Web-based presentations that are presented
by MasterCard staff and external companies that cover a range of SecureCode
topics.

These Web presentations are free to view and only require an e-mail address to
register and view the content.

Visit www.mastercard.com/securecode360 to see available presentations and

to access the service.

MasterCard SecureCode Hosted ACS Service

The MasterCard SecureCode Hosted ACS Service—also known as MasterCard
OnLine Authentication—contains the infrastructure components required by
issuers to roll out a MasterCard SecureCode issuer platform in support of the
MasterCard SecureCode program. This bank-branded service offering includes
the Access Control Servers and Enrollment Service components for MasterCard®
and Maestro® programs.

For more information, please contact your MasterCard e-commerce

representative or send an e-mail to [email protected].

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 5-9
Chapter 6 Component Certificate Requirements
This chapter provides a general overview of the certificate requirements and component
authentication options available for implementation.

Overview ....................................................................................................................................... 6-1

Functional Certificate Authority Hierarchy..................................................................................... 6-1

Public Zone ............................................................................................................................. 6-2
Trusted Zone ........................................................................................................................... 6-2
Configuration Options ....................................................................................................... 6-2

Operational Certificate Authority Hierarchy................................................................................... 6-3

Certificates ............................................................................................................................... 6-4
Root Certificate .................................................................................................................. 6-4
Issuer Directory Subordinate Certificate............................................................................. 6-4
ACS Digital Signing Certificate ..................................................................................... 6-4
Issuer ACS Server Certificate........................................................................................ 6-5
Directory ACS SSL Client Certificate............................................................................. 6-5
Merchant MPI SSL Client Certificate ............................................................................. 6-5
Requesting Certificates............................................................................................................. 6-6

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 6-i
 Component Certificate Requirements
Overview

Overview
All components within a MasterCard® SecureCode™ infrastructure are required to
provide appropriate transport security to the data being passed between them.

This is accomplished by using the Secure Socket Layer (SSL) protocol, which
provides for the following:
• SSL Server Certificate Authentication—Provides a mechanism for the client
(for example, the party requesting the communication session) to assure
that the server sending the data is a trusted party.
• SSL Client Certificate Authentication—Similar to the server certificate
authentication except that it also allows the server to assure that the client
requesting the data is a trusted party. Failure of the SSL certificates to
authenticate will result in a failure of the communication session to establish.

Functional Certificate Authority Hierarchy

From a functional viewpoint, all certificates used by MasterCard SecureCode
solutions will be issued under either a public hierarchy maintained by a
commercial entity or under the MasterCard private hierarchy.

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 6-1
Component Certificate Requirements
Functional Certificate Authority Hierarchy

Public Zone
The inclusion of a transaction flow in the public zone is a direct result of
the requirement for a secure communication channel with the cardholder’s
browser. Because it is unrealistic to require cardholders to import a MasterCard
root certificate to participate in the protocol, all communication channels
within this zone must use SSL certificates that are created from a public root
hierarchy. The communication channels within this zone will be secured with
SSL server certificates only. The cardholder will not be required to have a
SSL client certificate.

MasterCard recommends that all communications within this zone be based

on 128-bit encryption ciphers.

The following table highlights the communication links, which fall within the
public zone.

MasterCard SecureCode Platform SSL-1 SSL-2 SSL-3 SSL-4

3-D Secure with SPA AAV Yes No No Yes

Trusted Zone
The inclusion of a transaction flow in the trusted zone is a direct result of
the requirement of a more trusted, secure communication channel between a
finite set of participants. As a result, this zone will contain all non-cardholder
communication channels.

The following table highlights the communication links for each MasterCard
SecureCode platform, which fall within the private zone.

MasterCard SecureCode Platform SSL-1 SSL-2 SSL-3 SSL-4

3-D Secure with SPA AAV No Yes Yes No

Configuration Options
The 3-D Secure with SPA AAV issuer platform has the following configuration
requirements within the private zone:

For the SSL-2 link:

• The merchant plug-in must use a SSL client certificate based on the
MasterCard private hierarchy. If a processor is using the merchant plug-in,
MasterCard does not require an individual certificate for each merchant.
However, the processor will be required to use a separate and distinct client
certificate for each applicable acquirer.
• The Directory will require an SSL server certificate based on a public
hierarchy. At the time of publication, the root is a VeriSign® certificate.

©2005–2011 MasterCard. Proprietary. All rights reserved.

6-2 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 Component Certificate Requirements
Operational Certificate Authority Hierarchy

For the SSL-3 link:

• The Directory will use an SSL client certificate based on a MasterCard
private hierarchy.
• The ACS must use an SSL server certificate based on a MasterCard private
hierarchy. In order for this to provide the proper level of security, the
following configuration issues must be addressed:
– The URL for connectivity with the Directory must be different than the
one used for connectivity with the cardholder.
– The Directory URL must be configured to accept only certificates based
on the MasterCard root certificate. Failure to present a proper certificate
from the MasterCard hierarchy must result in a failed session attempt.

Operational Certificate Authority Hierarchy

The MasterCard certificate authority will be used to issue specific MasterCard
private hierarchy end-entity and subordinate certificates only. All public rooted
certificates used by the MasterCard SecureCode issuer platforms must be
obtained from commercially available sources.

The following table indicates responsibility for creating, signing, and managing
the various roots, subordinates, and end entity certificates in the hierarchy.

Certificate Creation Signing Maintenance

MasterCard Root MasterCard MasterCard MasterCard
Issuer/Directory Subordinate MasterCard MasterCard MasterCard
Acquirer Subordinate MasterCard MasterCard Acquirer

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 6-3
Component Certificate Requirements
Operational Certificate Authority Hierarchy

Certificate Creation Signing Maintenance

Issuer/Directory Signing MasterCard MasterCard MasterCard
End-Entity
Issuer/Directory SSL Server MasterCard MasterCard MasterCard
End-Entity
Issuer/Directory SSL Client MasterCard MasterCard MasterCard
End-Entity
Acquirer SSL Client Acquirer Acquirer Acquirer
End-Entity

Certificates
Following is information about different types of certificates.

Root Certificate
The MasterCard CA has created the root certificate specifically for SecureCode.
It is self-signed and is shared by MasterCard and Maestro.

Validity Period: 10 Years

Key Size: 2048 bits

Issuer Directory Subordinate Certificate

This subordinate certificate has been created by the MasterCard CA and signed
by the MasterCard root. It is used to sign all end-entity certificates used for
communication between the MasterCard Directory and issuer access control
servers.

Validity Period: Through the validity of the root

Key Size: 2048 bits

ACS Digital Signing Certificate

This end-entity certificate, based on certificate requests received from issuer

access control server implementations, will be created by the MasterCard CA
and signed by the Issuer/Directory subordinate certificate. It is used by the
issuer’s access control server to digitally sign all payer authentication response
messages returned to the merchant.

©2005–2011 MasterCard. Proprietary. All rights reserved.

6-4 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 Component Certificate Requirements
Operational Certificate Authority Hierarchy

Validity Period: 4 Years

Key Usage Period 3 Years
The difference between the validity and key usage
periods is a direct result of having to perform
authentications on transactions after the key usage
period has expired.
Key Size: 1024 bits

Issuer ACS Server Certificate

This end-entity certificate, based on certificate requests received from issuer

access control server implementations, will be created by the MasterCard CA
and signed by the Issuer/Directory subordinate certificate. These certificates
are used by the issuer access control server to establish SSL communications
with the MasterCard Directory server.

Validity Period: Through the validity of the root and associated

subordinate
Key Size: Recommended—2048 bits
Minimum—1024 bits

Directory ACS SSL Client Certificate

This end-entity certificate will be created by the MasterCard CA and signed

by the Issuer/Directory subordinate certificate. These certificates are used by
the MasterCard Directory server to establish SSL communications with issuer
access control server implementations.

Validity Period: Through the validity of the root and associated

subordinate
Key Size: Recommended—2048 bits
Minimum—1024 bits

Merchant MPI SSL Client Certificate

This end-entity certificate will be created by the MasterCard CA and signed

by the Acquirer subordinate certificate. These certificates will be used by
the merchant components to establish SSL client communication using the
MasterCard private hierarchy.

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 6-5
Component Certificate Requirements
Operational Certificate Authority Hierarchy

Validity Period: May be up through the expiration date of the Root and
Acquirer subordinate CA certificates.
Key Usage Period Recommended—2048 bits
Minimum—1024 bits
The difference between the validity and key usage
periods is a direct result of having to perform
authentications on transactions after the key usage
period has expired.
Common Name (CN): The common name must be populated with one of the
following characteristics of the site that will use the
certificate:
Domain Name For example
www.merchant.com
Externally visible IP For example 1.2.3.4
address
Externally visible IP For example
address range 1.2.3.0–1.2.3.255
Organizational Unit (OU) Name of the merchant or merchant processor (if
applicable) requesting the certificate.
Acquirer BIN, as indicated For example
in the associated acquirer 543210:Acquirer Name
enrollment forms, and
Name of the acquirer.
The two fields must be
separated by a colon.
Country Country where the merchant or merchant processor
is located. This should be the ISO 3166 2 character
country code (for example, U.S.)

Requesting Certificates
For more information about the certificate request process, please refer to the
MasterCard SecureCode Production Procedures publication. Copies of this
document are available on request from [email protected]. All
requests that fail to follow the published procedures will be rejected.

©2005–2011 MasterCard. Proprietary. All rights reserved.

6-6 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
Chapter 7 Issuer Authentication Options
This chapter introduces and describes the various authentication options available to issuers.

Background ................................................................................................................................... 7-1

Static Password .............................................................................................................................. 7-1

Random Static ................................................................................................................................ 7-2

SMS ................................................................................................................................................ 7-2

Mobile Application......................................................................................................................... 7-4

CAP................................................................................................................................................ 7-4

Display Card .................................................................................................................................. 7-5

Other Authentication Options........................................................................................................ 7-6

Virtual Card Numbers .............................................................................................................. 7-7

Risk Based Authentication ............................................................................................................. 7-7

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 7-i
 Issuer Authentication Options
Background

Background
Perhaps the most important issuer decision in a MasterCard® SecureCode™
implementation is how to authenticate the cardholder, and in case of a
transaction dispute, provide evidence of authentication.

The decision will differ depending on the issuer’s view and the attitude to risk.
While issuers must evaluate the risk/reward of these options, this section will
focus on explaining some of the available options.

Another consideration is whether a single authentication option fits with the

issuer’s strategy. The needs of an issuer’s cardholders differ depending on the
market segmentation of the issuer’s portfolio.

A common issue with any authentication solution used by an issuer is

communicating the option(s) available, how a cardholder can either opt in to
the service or use the provided application or tokens.

Static Password
MasterCard launched the MasterCard SecureCode static password in 2002, as an
entry level initial deployment that could be quick to market, not as a long term
strategy. Much of this publication is still aimed at this proposition, therefore,
it does not provide in-depth detail.
• Quick to market.
• Relies on a static password and usually on static data to identify the
customer when they enroll.
• Know your customer, Identification and Verification (ID&V), is important
to ensure that fraudsters can neither enroll in the service on behalf of a
genuine cardholder, nor change the password of an enrolled cardholder.
• Activation During Shopping (ADS) produces good enrollment results for an
issuer, but interrupts the shopping experience. It is important to follow the
practices identified in this publication, because if executed poorly, ADS can
cause genuine cardholders to abandon transactions. Additional information
is available in the MasterCard SecureCode Issuer Best Practices.
• Needs communication to cardholders to ensure that they are aware of the
SecureCode process before they are requested to enroll, especially in the
case of ADS.

Although static password was a common solution in the past, new deployments
where SecureCode deployment is strong such as the the Asia/Pacific, South
Asia/ Middle East/Africa and Europe regions, are moving to a dynamic solution.

To avoid the issues surrounding ID&V some issuers using static password
have undertaken a “PIN Mailing” whereby all existing cardholders receive
a SecureCode through the mail with full information on its use. Making
SecureCode part of the card opening procedures is also gaining in popularity.

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 7-1
Issuer Authentication Options
Random Static

Random Static
Random static is a variant of a static password solution that some issuers have
chosen to deploy. It is similar to that seen for some banks Internet banking
solutions. Although the cardholder still has a static password, they are never
asked to complete the entire password when prompted but rather a random
selection of characters from the password. For example, first, sixth, and ninth
are depicted in Figure 7.1.

Figure 7.1—Random Static Password Entry

This method is an improvement in security, but makes the cardholder

experience more challenging, especially if the issuer chooses to enforce
password requirements such as minimum 9, or must be alphanumeric.

The same issues stated above for Static Password are also seen and should be
considered in this deployment.

SMS
The use of Short Message Service (SMS) has grown in popularity with the
advantage that almost any phone issued today can support this communication
method. Banks use this method to send alerts to their customers, and it can
now be used as an authentication method for MasterCard SecureCode.

©2005–2011 MasterCard. Proprietary. All rights reserved.

7-2 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 Issuer Authentication Options
SMS

The generation of a dynamic code that is sent to the registered hand set can
be undertaken in a number of ways and issuers should discuss this with their
Access Control Server (ACS) vendor. One way that MasterCard undertakes this
is through the use of a CAP (Chip and Pin) authentication server. This single
server could be used for validation of CAP, Mobile Application and Display
card values, and the generation of SMS passwords. In addition to re-using
investments made in EMV, this method allows Chip issuers to examine a
solution that could support several authentication options.

The advantage to the cardholder is not having to remember a password because

when the card is used at an e-commerce merchant that supports MasterCard
SecureCode, the dynamic code can be sent to the registered mobile phone.
Issuers could also consider alerts from their systems to the phone which advise
the cardholder of the amount spent at any e-commerce merchant—even if
SecureCode is not used.

The cardholder experience will be similar to that of a static password as

depicted in Figure 7.2.

Figure 7.2—SMS

It is important to ensure that the mobile phone number used is trusted as

owned by the cardholder, and that a back-up mechanism is in place for
instances when a cardholder is unable to obtain a mobile signal.

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 7-3
Issuer Authentication Options
Mobile Application

Mobile Application
Smart phones are growing in issuance and in popularity. The number of
mobile applications is also growing rapidly. MasterCard has a growing number
of mobile applications, some of which, such as Google Wallet, are not yet
available globally.

One option that is available globally is the Advanced Authentication for Mobile
application. This application resides on the smart phone and allows a secure
software application to have the equivalent of the consumers chip card on
the phone. This solution allows the cardholder to have a similar experience
that they would in a face-to-face chip transaction. The customer, opens the
application, enters their PIN, and obtains a generated SecureCode, which is
then used in the usual box required by their issuer.

Figure 7.3—Mobile Application

The issuer can verify the password by using the same “black box” solution
available for any EMV-generated authentication.

Ensuring that the application is delivered to the cardholders mobile phone will
be a key consideration in this deployment.

CAP
Perhaps the closest user experience to the face-to-face channel that a Chip and
Pin (CAP) cardholder can experience is through the use of a CAP device as
depicted in Figure 7.4.

©2005–2011 MasterCard. Proprietary. All rights reserved.

7-4 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 Issuer Authentication Options
Display Card

Figure 7.4—CAP Device

In this case, a cardholder would insert their card into the reader and follow the
prompts on the device to enter their pin and generate their SecureCode.

Security can be increased by entering other information before entering the

PIN, for example, a dynamic challenge that the issuer could display when
prompting for the SecureCode.

Balance needs to be maintained between the user experience and the chance
for fraud. For example, an issuer may decide that a simple PIN driven
SecureCode would be sufficient for amounts under a defined threshold with
increased requirements for high-value items.

This may not be a practical solution for cardholders that shop from multiple
devices and locations. For those that shop either from home or work, this
added security and simple cardholder experience may be appealing.

Display Card
MasterCard has launched a new card design that integrates the CAP reader into
the card in two designs, as depicted in Figure 7.5. In the first design, the act
of pushing a single button will generate a one time code in the display. For
increased security, there is a second option that works like the CAP reader in
that it requires the cardholder to first input their PIN.

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 7-5
Issuer Authentication Options
Other Authentication Options

Figure 7.5—Display Card Example

These cards can be configured to also work with the CAP reader to provide
both options for generating the SecureCode.

The Display Card is still based on the EMV standard and the same “black box”
solution that would check the authentication from Mobile Authentication and
CAP can be used to verify the number generated by the display card.

These cards are available for all MasterCard cards including credit, debit and
Maestro®.

Other Authentication Options

MasterCard SecureCode has the flexibility to accommodate many authentication
options that ensure both the integrity of the program and of the authentication.
For example, internet banking solutions with key fobs, RSA secure tokens
and software, as well as many others.

MasterCard can investigate deployment availability for issuers that have an

existing authentication method. Non-standard deployments will require a
thorough review by MasterCard, and agreement must be reached on screen
design, and other features and options. Therefore, MasterCard should be
involved early in any deployment discussion.

Send an e-mail message for more information about additional options or an

authentication concept to [email protected].

©2005–2011 MasterCard. Proprietary. All rights reserved.

7-6 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 Issuer Authentication Options
Risk Based Authentication

Virtual Card Numbers

In reality the problem faced by an issuer is that they are liable for transactions
that occur at a merchant that has deployed SecureCode.

Virtual Card Numbers can be a strong issuer and cardholder solution if the
numbers are generated in a secure way.

Solutions, such as the inControl offering from MasterCard, can add further value
through features such as cardholder alerts, prohibitions from using the card at
certain merchants/MCCs, and maximum value of purchase. This can be used
for any card but is particularly popular for commercial cards.

Unfortunately a merchant can not distinguish if it is a real or a virtual card, or

the level of security that may have occurred. An issuer can have an ACS that is
configured to work with the inControl platform to provide the merchant with a
valid fully authenticated transaction avoiding any potential acceptance issues.

When the virtual card is used, this integration avoids the cardholder being
prompted for an additional SecureCode password, and also delivers the fully
authenticated response to the merchant in silent mode. The added value is that
this integration can also, optionally, provide a failed authentication response to
the merchant if the real card is used, and an advice to the cardholder to use the
virtual card system supplied to fulfill the transaction.

For more information on inControl and SecureCode options, contact your

MasterCard representative.

In summary, virtual cards have the following characteristics:

• Strong issuer response securing transactions for all Internet purchases both
current and future. Benefits include:
– Real card number are not used for Internet purchases
– Flexibility to be static, or a one-time generated virtual number
• Strong when integrated with SecureCode by the issuer using inControl and
SecureCode Issuer ACS for “silent” authentication.
• Weak from a merchant perspective:
– Merchant cannot identify if the card is virtual
– No chance of full authentication, which could trip fraud merchant
parameters

Risk Based Authentication

MasterCard SecureCode now supports a new approach called risk-based
authentication that focuses on when an issuer should authenticate a cardholder.

When SecureCode was launched in 2002, the assumption was that a merchant
deploying SecureCode would pass every transaction through the program to
gain the liability shift and available interchange incentives, and that an issuer
would want to authenticate every transaction.

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 7-7
Issuer Authentication Options
Risk Based Authentication

Current experience challenges this thinking and the integration of a risk engine
into the authentication experience balances the need to combat fraud with the
cardholder experience. There are several factors that will determine if fraud
is likely and cardholder authentication is required.

MasterCard produced a white paper, Advantages of a Risk Based Authentication

Strategy for MasterCard SecureCode, on this optional, risk-based authentication
that outlines the benefits, and details how the issuer can deploy this approach.
The white paper includes case studies from two vendors, and MasterCard can
confirm that this is also supported on our own Issuer Hosted Solution—Online
Authentication Service.

MasterCard remains committed to supporting the requirements of its issuing

and retailer customers and where required, continues to support 100 percent
authentication.

For more information on Risk-based Authentication, download the white paper

from www.mastercard.com/us/company/en/docs/rba_secure_code_HR.pdf,
and speak to your ACS provider about which options they support.

©2005–2011 MasterCard. Proprietary. All rights reserved.

7-8 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
Appendix A SecureCode SPA Algorithm Specifications
This appendix contains the layout of the Accountholder Authentication Value (AAV) to be used by
issuers participating in MasterCard® SecureCode™, as well as an overview of Base64 encoding.

Accountholder Authentication Value Layout..................................................................................A-1

Base64 Encoding ...........................................................................................................................A-1

Introduction .............................................................................................................................A-1
Examples .................................................................................................................................A-1
AAV Control Byte hexadecimal “8C” (Successful Cardholder Authentication) ...................A-2
AAV Control Byte hexadecimal “86” (Attempted Cardholder Authentication) ...................A-2
Base64 Alphabet ................................................................................................................A-3

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 A-i
 SecureCode SPA Algorithm Specifications
Accountholder Authentication Value Layout

Accountholder Authentication Value Layout

The format of the Accountholder Authentication Value (AAV) is defined and
described in the SPA Algorithm for the MasterCard Implementation of 3-D
Secure publication. This is a licensed publication available only to MasterCard
members or any non-member that has successfully executed the MasterCard®
SecureCode™ license agreement.

Base64 Encoding
The following overview of Base64 encoding is taken from RFC1521 “MIME
(Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying
and Describing the Format of Internet Message Bodies”. For more detailed
information, refer to www.ietf.org/rfc/rfc1521.txt?number=1521.

Introduction
Base64 encoding is designed to represent arbitrary sequences of octets in a form
that need not be humanly readable. The encoding and decoding algorithms
are simple, but the encoded data are consistently about 33 percent larger than
the un-encoded data.

A 65-character subset of US-ASCII is used, enabling 6 bits to be represented

per printable character. The extra 65th character, “=”, is used to signify a
special processing function.

The encoding process represents 24-bit groups of input bits as output strings
of four encoded characters. Proceeding from left to right, a 24-bit input group
is formed by concatenating three 8-bit input groups. These 24 bits are then
treated as four concatenated 6-bit groups, each of which is then translated into
a single digit in the Base64 alphabet. When encoding a bit stream via the
Base64 encoding, the bit stream must be presumed to be ordered with the
most-significant-bit first. That is, the first bit in the stream will the high-order
bit in the first byte and the eighth bit will be the low-order in the first byte,
and so on.

Each 6-bit group is then used as an index into an array of 64 printable

characters. The character referenced by the index is placed in the output
string. These characters, identified by Base64 Alphabet., are selected so that
they are universally representable. The set excludes characters with particular
significance to SMTP (for example: “.”, CR, LF).

Examples
The following examples will perform the beginning steps of Base64 encoding
of an AAV control byte field. The encoding process for the remainder of the
AAV will follow the same process.

The decoding process will simply work in reverse.

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 A-1
SecureCode SPA Algorithm Specifications
Base64 Encoding

AAV Control Byte hexadecimal “8C” (Successful Cardholder

Authentication)
Displaying hexadecimal 8C in its binary equivalent gives the following:

1 0 0 0 1 1 0 0

The data is then broken down into three 24-bit segments, which are interpreted
as four 6-bit segments for encoding. In this case, the first 6 bits equal:

1 0 0 0 1 1

Converting this to its decimal equivalent yields the following:

(1*25) + (0*24) + (0*23) + (0*22) + (1*21) + (1*20)

32 + 0 + 0 + 0 + 2 + 1

Decimal 35 = Base64 j

AAV Control Byte hexadecimal “86” (Attempted Cardholder

Authentication)
Displaying hexadecimal 86 in its binary equivalent gives the following:

1 0 0 0 0 1 1 0

The data is then broken down into three 24-bit segments, which are interpreted
as four 6-bit segments for encoding. In this case, the first 6 bits equal:

1 0 0 0 0 1

Converting this to its decimal equivalent yields the following:

(1*25) + (0*24) + (0*23) + (0*22) + (0*21) + (1*20)

32 + 0 + 0 + 0 + 0 + 1

Decimal 33 = Base64 h

©2005–2011 MasterCard. Proprietary. All rights reserved.

A-2 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 SecureCode SPA Algorithm Specifications
Base64 Encoding

Base64 Alphabet
Decimal Encod- Decimal Decimal Decimal
Value ing Value Encoding Value Encoding Value Encoding
0 A 1 B 2 C 3 D

4 E 5 F 6 G 7 H

8 I 9 J 10 K 11 L
12 M 13 N 14 O 15 P

16 Q 17 R 18 S 19 T

20 U 21 V 22 W 23 X

24 Y 25 Z 26 a 27 b
28 c 29 d 30 e 31 f
32 g 33 h 34 I 35 j

36 k 37 l 38 m 39 n

40 o 41 p 42 q 43 r

44 s 45 t 46 u 47 v

48 w 49 x 50 y 51 z

52 0 53 1 54 2 55 3

56 4 57 5 58 6 59 7

60 8 61 9 62 + 63 /

(pad) =

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 A-3
Appendix B Contact Information
This appendix contains names, areas of responsibility, and contact information for MasterCard
personnel who can assist members with e-commerce enrollment, testing, and implementation issues.

Contact Information .......................................................................................................................B-1

MasterCard SecureCode Online Resources ..............................................................................B-1

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 B-i
 Contact Information
Contact Information

Contact Information
This section contains contact information for MasterCard personnel who can
assist members with e-commerce enrollment, testing, and implementation
issues.

Area of Responsibility Contact Information

Completed and signed enrollment forms Send all completed and signed
enrollment forms to your MasterCard
regional representative. The regional
representative will forward the forms
to the appropriate electronic commerce
representative.
Maestro Customer Operations Services
U.S., Canada, Caibbean, Latin America,
South Asia/Middle East/Africa regions
Phone: 800-999-0363 (Inside U.S.)
636-722-6176 (Outside U.S.)
636-722-6292 (Spanish Language Support)
Fax: 636-722-7192
E-mail:
[email protected]
Europe region
Phone: +32-2-352-54-03
E-mail:[email protected]

Program Management Support [email protected]

Pricing/Billing
Support [email protected]

MasterCard SecureCode Online Resources

For additional information about MasterCard® SecureCode™, please visit one of
the following Web sites:
• Consumer Web site:
www.mastercard.com/securecode
• Certified SecureCode Vendors:
www.mastercard.com/us/merchant/solutions/securecode_vendor_list.html
• SecureCode FAQs:
www.mastercard.com/securecd/faq.do
• Merchant Web site:
www.mastercardmerchant.com/securecode
– Merchant FAQs: www.mastercard.com/us/merchant/assis-
tance/faqs.html#securecode
– Program Identifier Guidelines:
mastercardmerchant.com/securecode/artwork.html

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 B-1
Contact Information
Contact Information

Also, the e-business section of MasterCard OnLine® contains additional program

information.

©2005–2011 MasterCard. Proprietary. All rights reserved.

B-2 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
Appendix C Marketing Best Practices for Issuers
This appendix contains information related to the marketing of MasterCard® SecureCode™ solutions
by issuers to cardholders.

Consumer Positioning....................................................................................................................C-1
Key Consumer Messages .........................................................................................................C-1

Communication Strategy ................................................................................................................C-2

Online Stategy ...............................................................................................................................C-2

Issuer’s Site ..............................................................................................................................C-2
MasterCard Web Support .........................................................................................................C-2
Banner Ads ..............................................................................................................................C-3
Acquisition Stategy...................................................................................................................C-3
Confirmation of Enrollment E-mail ..........................................................................................C-3
Usage/New Merchant E-mail ...................................................................................................C-4
Mail Vehicles ............................................................................................................................C-4
Key Targets ........................................................................................................................C-4
Solo Mail and Other Media ................................................................................................C-4
Statement Inserts................................................................................................................C-4
Remind-to-Shop .................................................................................................................C-5

Available Marketing Materials ........................................................................................................C-5

MasterCard SecureCode Issuer Best Practice Guide .................................................................C-5

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 C-i
 Marketing Best Practices for Issuers
Consumer Positioning

Consumer Positioning
MasterCard recommends the following positioning for consumer
communications and marketing:

Introducing MasterCard® SecureCode™: Your own private code for added peace
of mind when shopping online.

It is a new service to enhance your existing MasterCard® card or Maestro®

card. Your own private code means added protection against unauthorized use
of your card when you shop online.

Each time you pay online at a participating merchant with your MasterCard card
or Maestro card, a message appears from your card issuer asking you for your
SecureCode—like the bank does at the ATM. In seconds, your issuer confirms it
is you and allows your purchase to continue.

To choose your SecureCode just follow the simple steps at

www.issuerwebsite.com.

MasterCard SecureCode. Added protection is that easy.

Key Consumer Messages

MasterCard has completed significant research regarding the marketing of
MasterCard SecureCode solutions to cardholders.

Based on that research, the following are recommendations to be considered in

developing key consumer messages:
• All messages should remind the cardholder that MasterCard SecureCode is
an enhancement to their existing MasterCard® card or Maestro® card and
applying for a new card is not necessary.
• All messages should imply ease of use, especially relating to registration
and shopping with MasterCard SecureCode. However, keep in mind that
consumers do not necessarily view technology as simple. As a result, avoid
“tech-heavy” language.
• Communications should speak to consumers’ concerns about online
security but not over promise what MasterCard SecureCode can deliver.
Additionally, no communications should imply that buying online without
MasterCard SecureCode is unsafe.
• The analogy of using a PIN at an ATM, shown in the positioning statement
was more effective than any other statement tested, including signature
at point-of-sale.
• Messages should avoid creating fear. Instead, the overall tone of the
message should be personal and reassuring, focusing on added peace of
mind when shopping online.
• Messages should include the words “new,” “introducing” and “free” (where
applicable).
• Should issuers decide to deploy a MasterCard SecureCode solution that
has no applet download, consumer copy should highlight “no software to
download” and “works from any computer.”

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 C-1
Marketing Best Practices for Issuers
Communication Strategy

• Market research has confirmed the stronger appeal of the term “SecureCode”
over the more common “password” or “PIN.”
• The first use (and the most prominent use if is not also the first use) of
the term “SecureCode”—indicating the secret code that cardholders enter
to authenticate themselves—should have a superscript “™”. Subsequent
uses of “SecureCode” on the same screen or document do not need to
include the “™”.

Communication Strategy
Communicating the availability of MasterCard SecureCode, and the cardholder
benefits it provides, are key to the success of the issuer’s program. This is
particularly true for Activation During Shopping (ADS) enrollment, where
cardholders must be educated about MasterCard SecureCode and notified
to expect the mid-purchase enrollment screen well in advance of their first
exposure.

Online Stategy
The following paragraphs describe the online strategy for positioning
SecureCode before consumers.

Issuer’s Site
The issuer’s site may contain a link to the informational pages at
www.mastercard.com/securecode or to other MasterCard consumer sites. These
pages include an explanation of what MasterCard SecureCode is and how it
works, a directory of participating merchants, links to participating issuers and a
frequently asked questions section. They also contain information specifically
targeted to cardholders who have never purchased online, which is designed to
allay their fears. Alternatively, issuers may wish to create their own Web pages,
to have on their own site, based on the www.mastercard.com/securecode pages.

MasterCard Web Support

The pages outlined previously are designed to support the issuer by:
• Using the MasterCard brand to increase relevance, appeal, and perceived
benefit of MasterCard SecureCode.
• Leveraging consumers’ perceptions of and behaviors towards security in
communicating about MasterCard SecureCode.
• Demonstrating that MasterCard is concerned about the online security of its
cardholders and seeks to help them feel comfortable about shopping online.
• Presenting MasterCard SecureCode as an added benefit of having a
MasterCard card and/or a Maestro card.

©2005–2011 MasterCard. Proprietary. All rights reserved.

C-2 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 Marketing Best Practices for Issuers
Online Stategy

• Segmenting the message to reassure non-buyers that shopping online is

safe and to encourage both non-buyers and light online buyers to purchase
online more frequently while assuring moderate to heavy buyers that
SecureCode will not slow down their purchase.
• Creating excitement about the product while clearly demonstrating how
simple it is to use.
• Creating easy-to-use, continually updated, directories of participating issuers
and merchants.

Banner Ads
MasterCard recommends that banner ads be used on the issuer’s home page
and relevant consumer sites to encourage enrollment. Banners should link
to the issuer’s information or registration page. These ads may also link to
the information pages at MasterCard consumer Web sites with sections on
MasterCard SecureCode.

Acquisition Stategy
The broadest range of cardholders will enroll through a combination of
Activation During Shopping enrollment tactics and direct mail media. This
appendix reviews recommendations for each of those vehicles. In addition to
the direct mail communications, MasterCard also offers a variety of SecureCode
statement messages. With the advent of “phishing” and other spoof messages,
MasterCard no longer recommends the use of e-mail for acquisition purposes.
However, e-mail is effective for confirming enrollment.
DEFINITION
Phishing refers to the act of sending fraudulent e-mails to e-mail users. Typically, the goal of these
e-mails is to obtain personal information from the e-mail user with the intent to commit identity
theft.

Confirmation of Enrollment E-mail

MasterCard recommends that the enrollment confirmation e-mail:
• Thank the cardholder for registering.
• Remind consumers not to forget their SecureCode and user ID—if
required—and to store it in a safe place.
• Reiterate the benefits of using SecureCode, and remind cardholders that the
service works automatically at program merchant sites.
• Mention the SecureCode account management functionality. Include a link
to the account management login page and encourage cardholders to
bookmark the page.

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 C-3
Marketing Best Practices for Issuers
Online Stategy

Usage/New Merchant E-mail

The goal is of these e-mail messages is to remind enrollees of MasterCard
SecureCode, its benefits, how and where to use it, and new merchants that
become available. Also, these e-mail messages can remind enrollees to review
their transactions online and to periodically update their profile.

Mail Vehicles
The following paragraphs outline how to position SecureCode before the
consumer using direct mail service.

Key Targets
Direct mail offers a way to reach cardholders who may be less Web-savvy
or unfamiliar with their issuer’s Web services. This more traditional form of
communication lets you reach the light-shoppers and non-shoppers.

Key direct mail lists include:

• Customers who are comfortable with card not present transactions such
as mail order/telephone order (MOTO), recurring payments, installment
payments, and deferred payments.
• Segmentation based on the profile of U.S. online shoppers:
– Household income greater than USD 75,000
– Range in age from 25–54, but tend to skew younger within this range
– Well-educated, for example, college level or above
– Tend to rent rather than own their own residence
• Indicators of adoption such as active card use within the last six months or
use of phone-based account management services

Solo Mail and Other Media

MasterCard recommends sending a self-mailer, a prominent tactic to introduce
MasterCard SecureCode, as a more cost-efficient means than a letter/envelope
package. This piece should include screenshots to help recipients visualize the
ease of use and integration with the typical online shopping process. Issuers
may also want to include the URL to visit for additional information or to view
the demo. This mailer should be followed within 2–3 weeks by a registration
reminder message, which can appear as a statement message or statement
brochure.

Statement Inserts
Statement inserts and postcards can be used in any combination to remind
cardholders to register for MasterCard SecureCode. The first reminder should
be sent 2–3 weeks after the drop of the self-mailer. If the statement insert
schedule is full, the postcard may be used. The timing of this follow up is
critical to improve response rates.

©2005–2011 MasterCard. Proprietary. All rights reserved.

C-4 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 Marketing Best Practices for Issuers
Available Marketing Materials

MasterCard recommends heavier use of electronic communications with

cardholders that issuers know are comfortable online—for example, online
registrants and online bankers. MasterCard recommends that issuers send
a statement insert once a year to their portfolio and include statement
messages—particularly during the fourth quarter.

Remind-to-Shop
Remind-to-shop postcards are another high-impact way to build usage,
particularly among those cardholders who may not have been comfortable
enough in the past to explore shopping on the Web.

Timing of the “remind-to-shop” postcards should be staggered with the

“remind-to-shop” e-mail messages to maximize the impact of the message over
time.

Available Marketing Materials

MasterCard has a variety of sample marketing materials, including a
Flash Demo which depicts the basic flow of a SecureCode authen-
tication while shopping online, and a suggested list of Frequently
Asked Questions (FAQs). The MasterCard SecureCode Toolkit with
customizable marketing materials is available on mastercard.com using
the following Web address: http://www.mastercard.com/us/merchant/secu-
rity/what_can_do/SecureCode/toolkit/SecureCode.html.

Additionally, issuers developing their own media or software solutions must be-
come familiar with the MasterCard SecureCode Program Identifier Usage Guide-
lines available via the following Web address: www.mastercard.com/us/mer-
chant/security/what_can_do/pdf/SecureCode_logo_usage.pdf and other
pertinent requirements.

MasterCard SecureCode Issuer Best Practice Guide

Access the MasterCard SecureCode Issuer Best Practice Guide on the
Resources page on mastercard.com via the following Web address:
www.mastercard.com/us/company/en/whatwedo/resources.html.

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 C-5
Appendix D Maestro Considerations
This chapter contains detailed information about specific processing issues associated with Maestro®
and MasterCard® SecureCode™. Merchants should contact their acquirer for specific authorization
and clearing requirements.

Account in Good Standing............................................................................................................ D-1

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 D-i
 Maestro Considerations
Account in Good Standing

Account in Good Standing

An account in good standing transaction is a request by a merchant to check the
authenticity of a Maestro® account number. Unlike other Maestro transactions,
Account in Good Standing is not a financial transaction. It does not perform a
value check or guarantee that the customer has sufficient funds to cover the
purchase. The objective is to satisfy the merchant’s primary concern to ensure
that the Maestro card number being provided by the customer is not counterfeit.

Merchants must not confuse an Account in Good Standing transaction with a

pre-authorization transaction used for self-service pumps at petrol/gas stations.
These transactions are used to guarantee a block of funds up to the amount
in the transaction, provided it is followed within 20 minutes by a completion
transaction.

An account in good standing transaction is a standard authorization message

with the following specific data content requirements.

Data Element Name Value

4 Transaction Amount One unit of purchase

currency

61, subelement 7 Point-of-Service Data 4 = Preauthorized Request

(POS) Transaction Status
Indicator

These data elements must be used by the acquirer when placing an Account
in Good Standing transactions. Each acquirer is responsible for determining
how this transaction is supported in the point of interaction message defined
for the merchant to acquirer interface.

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 D-1
Appendix E MasterCard Advance Registration Program
This appendix introduces the MasterCard Advance Registration Program and identifies the program
requirements.

MasterCard Advance Registration Program .................................................................................... E-1

Participation Requirements for Merchants ............................................................................... E-1
MARP Merchant Use of MasterCard SecureCode...................................................................... E-2
Acquirer Impact ....................................................................................................................... E-3
Issuer Impact ........................................................................................................................... E-3

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 E-i
 MasterCard Advance Registration Program
MasterCard Advance Registration Program

MasterCard Advance Registration Program

MasterCard Advance Registration Program (MARP) was introduced for Maestro
in 2008, and for MasterCard in 2010. MasterCard has reminded issuers that the
support of MARP is mandatory and that issuers cannot selectively accept only
the full MasterCard® SecureCode™ transactions.

Further, MasterCard is also introducing a simplified structure for Static AAVs

used to support the program to minimize the long term impact of the program
on issuers.

The program is designed to encourage participating merchants to implement

MasterCard SecureCode and use it as part of a risk-based authentication
strategy for high-risk e-commerce transactions. This provides the merchants
with flexibility and control over the check-out experience. Valid e-commerce
transactions under MARP can be initiated through a mobile device or a
computer.

To participate, a merchant must demonstrate a commitment to ensuring both a

positive customer checkout experience and a robust risk management system.

Participation Requirements for Merchants

MARP is open to e-commerce merchants that accept MasterCard® cards,
Maestro® cards, or both, and that provide customers with a positive, secure
e-commerce shopping experience. For each merchant, the acquirer will
complete a participation request form designed to help MasterCard understand
the merchant’s e-commerce acceptance environment. MasterCard staff will
review the participation request form, and notify the acquirer if the merchant
has been enrolled in the program.

To be eligible for this program the merchant must enable customers to register
on the merchant's Web site by selecting a username and password or similar
credentials, and provide cardholders with the option to register a MasterCard or
Maestro card number for use in future e-commerce transactions. The merchant
will also be expected to satisfy minimum security requirements intended
to help ensure the protection of all participants: the merchant, its acquirer,
the issuer, and the cardholder. The merchant must offer customers a safe,
secure shopping experience by using best practice risk management tools. In
addition, the merchant must demonstrate a commitment to conducting business
in a manner that does not result in excessive chargebacks. More information
about the program, including the program terms and the merchant enrollment
process, are available on MasterCard OnLine®. From the Main Menu, select
e-Business, then e-Commerce, and then click MasterCard and Maestro
Advance Registration Program.

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 E-1
MasterCard Advance Registration Program
MasterCard Advance Registration Program

MARP Merchant Use of MasterCard SecureCode

MARP enables enrolled merchants to authenticate e-commerce transactions as
follows:
• The merchant invites the customer to register on its Web site by choosing a
username and password, or similar credentials acceptable to MasterCard,
and must provide the customer with the option to register a MasterCard or
Maestro card account number for use in future e-commerce transactions.
• For the first MasterCard® or Maestro® e-commerce transaction, the merchant
must request MasterCard SecureCode authentication before submitting the
transaction for authorization. If that transaction is subsequently authorized
by the issuer, it is guaranteed to the acquirer or its merchant, regardless of
whether the issuer or cardholder participates in MasterCard SecureCode as
determined by the merchant request.
• If the first MasterCard or Maestro e-commerce transaction for the cardholder
registered with the merchant is authorized by the issuer, the merchant can
skip the MasterCard SecureCode authentication on subsequent transactions
by the same customer using the same MasterCard or Maestro card account.
In that case, the merchant will populate:
– Data Element (DE) 48, (Additional Data Private Use, subelement 32
(MasterCard Assigned ID) in the Authorization Request/0100 message
with an ID assigned by MasterCard.
– DE 48, subelement 43 (3-D Secure for MasterCard SecureCode) in the
Authorization Request/0100 message with a MasterCard-assigned static
Account Authentication Value (AAV).
– DE 48, subelement 42, position 3 (UCAF Collection Indicator) in the
Authorization Request/0100 message with a value of 3.
– Private data subelement 0052 (Electronic Commerce Security Level
Indicator) subfield 3 (UCAF Collection Indicator) in the clearing record
submitted to GCMS for processing (where applicable) with a value of 3.
– The PDS 176 (MasterCard Assigned ID) in the clearing record submitted
to GCMS for processing with an ID assigned by MasterCard.
• If the merchant populates the UCAF with the static AAV assigned by
MasterCard, and populates the UCAF Collection Indicator with the value of
3, and the issuer authorizes the transaction, the issuer will have a right to
charge back the transaction for reason of fraud.
• If a registered cardholder uses a different MasterCard or Maestro
card account number for a transaction, the merchant must request
MasterCard SecureCode authentication before submitting the transaction
for authorization.
• Based on a risk assessment, the merchant always has the option of
requesting MasterCard SecureCode authentication for any MasterCard or
Maestro transaction, in which case the transaction will be governed by
existing MasterCard SecureCode and Chargeback rules. For instance,
for consumer cards acquired in the Europe region, if the transaction is
subsequently authorized by the issuer, it is guaranteed to the acquirer or
its merchant, regardless of whether the issuer or cardholder participates in
MasterCard SecureCode as determined by the merchant request.

©2005–2011 MasterCard. Proprietary. All rights reserved.

E-2 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 MasterCard Advance Registration Program
MasterCard Advance Registration Program

Acquirer Impact
Participation in MARP is optional for Europe region acquirers. Acquirers outside
the Europe region are not eligible to participate in the program.

Effective 9 November 2010:

• Acquirers authorization systems must support a value of 3 in the UCAF
Collection Indicator (DE 48, subelement 42, position 3) in the Authorization
Request/0100 message.
• Acquirers may submit qualifying transactions with the UCAF Collection
Indicator (PDS 0052, subfield 3) in the First Presentment/1240 message
containing a value of 3 and with an Interchange Rate Designator (IRD)
applicable for the Full-UCAF Interchange Tier, as defined in the Interchange
and Service Fees—Europe Region manual.

Acquirers that would like to enroll a merchant for the program may do so by
following the enrollment process that is available on MasterCard OnLine®.
From the Main Menu, select, e-Business, then e-Commerce, and then click
MasterCard and Maestro Advance Registration Program.

Issuer Impact
Any Maestro issuer that supports e-commerce is required to support the static
AAV in authorization. Issuers must ensure and meet existing European regional
requirements to support Maestro e-commerce transactions.

Current requirements can be found in the latest Authorization specifications,

and if applicable, GCMS manuals available on the Member Publications product
on MasterCard OnLine®.

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 E-3
Appendix F Issuer Implementation Process
This appendix contains detailed information about the issuer implementation process for
MasterCard® SecureCode™.

Overview ....................................................................................................................................... F-1

Business User Requirements .......................................................................................................... F-1

Access Control Server Vendor Selection ........................................................................................ F-1

Dynamic Authentication Vendor Selection............................................................................... F-1

Issuer Program Enrollment ............................................................................................................ F-1

Testing Requirements..................................................................................................................... F-1

Testing Process ........................................................................................................................ F-2
Enrollment Screen/Marketing Material Review ........................................................................ F-2
Completion of Testing ............................................................................................................. F-2

SecureCode in Production.............................................................................................................. F-2

Certificate Request Process ...................................................................................................... F-2
Loading Card Ranges ............................................................................................................... F-2
Directory Server Update Schedule ........................................................................................... F-3
Issuer Program Launch ............................................................................................................ F-3

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 F-i
 Issuer Implementation Process
Overview

Overview
This chapter contains detailed information about the Issuer Implementation
Process for MasterCard® SecureCode™ including vendor selection, enrollment,
testing requirements, and more.

Business User Requirements

This first step should determine the issuer’s willingness for risk (for example
Risk Based Authentication or all transactions), and the static or dynamic options
that they wish to consider and/or implement.

Access Control Server Vendor Selection

Issuer selects a software vendor or hosted service platform to provide
the Access Control Server (ACS) and enrollment server for the
SecureCode program. Issuers must ensure that the vendor has a product
that is compliant with the MasterCard SecureCode program. For a complete
list of products that are compliant with SecureCode, please refer to
www.mastercardmerchant.com/securecode/vendors.html.

Dynamic Authentication Vendor Selection

Issuers choosing to use a dynamic token to work with the Issuer ACS may need
to contact other vendors to source this token.

Issuer Program Enrollment

Issuers must enroll in the SecureCode program by completing the SecureCode
program general and issuer enrollment forms. The forms should be completed
and sent via e-mail message to the SecureCode program administrator at
[email protected]. In addition, a signed, hardcopy original form
must be sent to the regional office for processing.

Testing Requirements
All issuers must participate in functional testing of their SecureCode
implementation prior to being issued production credentials. Upon receipt
of the signed SecureCode program enrollment forms, the SecureCode test
administrator will send all testing documentation to the member. Issuers
must return the completed testing enrollment form via e-mail message to
[email protected] to schedule a test session.

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 F-1
Issuer Implementation Process
SecureCode in Production

Testing Process
Issuers will perform the test cases detailed in the testing documentation and
submit the test results form and the .XML for each of the 3D secure messages
associated with each test case to MasterCard for review. All test results should
be sent via e-mail message to [email protected].

Enrollment Screen/Marketing Material Review

All issuers must submit all cardholder-facing screens, including enrollment
screens, the authentication screens, and the Activation During Shopping
screens to MasterCard for review and approval. Screens can be sent at any
time, even before scheduling testing. All issuers must adhere to the screen
requirements and marketing guidelines detailed in Chapter 4, Customer
Interface Requirements. For issuers implementing Activation during Shopping,
all marketing communications plans must be approved by MasterCard in
advance of program launch.

Completion of Testing
Upon successful approval of the test results and the screens, issuers must print,
sign, and mail the test results form to the SecureCode test administrator.

SecureCode in Production
Upon approval of the test results and screens, MasterCard will send a
Production Procedures guide to the issuer for guidance on requesting the
necessary certificates and for loading card ranges in the MasterCard SecureCode
directory server. The issuer is then approved for production and can launch
their program when ready.

Certificate Request Process

The issuer must submit a request for a production level issuer digital signing
certificate/single sockets layer (SSL) server certificate. All certificate requests
must be submitted by the designated certificate agent as identified by the
issuer on the program enrollment form. All certificate requests must be sent
to [email protected] for processing. The signed certificate will be
returned to the issuer within four business days.

Loading Card Ranges

The request to load card data must be submitted to securecode_sup-
[email protected] using the customized card range file layout provided by
MasterCard upon completion of testing. The card ranges must be submitted by
the authorized agent as identified on the program enrollment forms.

©2005–2011 MasterCard. Proprietary. All rights reserved.

F-2 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 Issuer Implementation Process
SecureCode in Production

NOTE
To prevent delay in customer live service, card ranges can be loaded prior to the production launch
date.

Directory Server Update Schedule

Currently, MasterCard updates the production directory server twice per week,
on Wednesdays and Fridays. This is subject to change. Please refer to the
Production Procedures guide for current schedule.

Issuer Program Launch

Once an issuer has officially launched their SecureCode program, MasterCard
would like to include the issuer on the participating issuers’ Web site. Issuers
should provide the name of the financial institution exactly as it should appear
on the site and the enrollment URL. MasterCard will create a link to the
enrollment site to facilitate cardholder enrollment in the program. The name
and enrollment URL should be sent to [email protected].

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 F-3
Appendix G AAV Validation Service Implementation
Process
This appendix outlines the AAV Validation Service implementation process as it relates to
MasterCard® SecureCode™.

Overview ...................................................................................................................................... G-1

Prerequisites ........................................................................................................................... G-1

Issuer Program Enrollment ........................................................................................................... G-1

Key Exchange Process .................................................................................................................. G-2

Testing Requirements.................................................................................................................... G-2

Authorization Testing.............................................................................................................. G-2
AAV Key Validation................................................................................................................. G-3

AAV Validation Service in Production ........................................................................................... G-3

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 G-i
 AAV Validation Service Implementation Process
Overview

Overview
MasterCard recommends, but does not require, that issuers validate the SPA AAV
in real-time prior to generating the authorization response. In support of this
activity, MasterCard has made available an “on-behalf-of” SPA AAV validation
service.

Issuers may enroll in either of the following AAV verification services:

• MasterCard SecureCode AAV Verification Service—MasterCard offers the
AAV Verification service on every authorization transaction that contains
UCAF data regardless of whether the issuer’s host system is available or
unavailable to respond to the Authorization Request /0100 message.
• MasterCard SecureCode Dynamic AAV Verification in Stand-In
Processing—MasterCard offers the AAV Verification service for authorization
transactions processed by Stand-In processing that contain UCAF data.

Prerequisites
Issuers must be enrolled in the MasterCard® SecureCode™ program in order to
enroll for the on-behalf-of service. Issuers must ensure that their authorization
systems can accept the additional data in the authorization message indicating
the result of the AAV validation.

Issuer Program Enrollment

Enrollment in the AAV Validation Service is through MasterCard OnLine®. The
service is located in the Product Catalog as SecureCode AAV Validation Service.
All enrollment requests are sent internally via MasterCard OnLine where the
application is checked and verified before being approved for participation
in the program. Additionally, a project may be initiated with your regional
Customer Implementation Services team.

Approval of the enrollment application will result in the issuer being contacted
by several MasterCard groups who will work with the issuer to implement
this service.

These groups are:

• SecureCode Testing Team—([email protected])—The
SecureCode test team will contact the issuer and confirm enrollment in the
program. Issuers will be provided with an overview of the implementation
steps and timeframes. At this time, the test team will gather additional
implementation details such as the service option: always perform AAV
validation or perform AAV validation in stand in only. If stand in only, the
issuer will be requested to complete the decision matrix. The issuer will
also be required to identify the bins that will participate in the service.
• Regional Customer Interface Specification Customer Implementation
Services Team—The appropriate Customer Implementation Services team
will contact the issuer within five business days to coordinate authorization
testing.

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 G-1
AAV Validation Service Implementation Process
Key Exchange Process

• Issuers will also receive an overview of the implementation steps and

timeframes. At this time, the test team will gather additional implementation
details such as the service option: always perform AAV validation, or
perform AAV validation in Stand-In only. If Stand-In only, the issuer will be
requested to complete the decision matrix. The issuer will also be required
to identify the BINS that will participate in the service.
• Key Management Team—The Key management team will contact the
member to coordinate the key exchange process. Refer to the On-behalf
Key Management Document Set available in Member Publications on
MasterCard OnLine for complete details on this process.

Key Exchange Process

This process involves the registration of Security Officers authorized to
exchange the keys with MasterCard and the use of the Crypto Self-Test Tool
to perform the key exchange. Implementation timeframes can vary greatly
depending on the Security Officer Registration process and the submission
of the appropriate registration forms.

Security Officer Registration—Members must complete the PSS1a & PSS15a

registration forms. If a member delegates the key exchange to a processor or
other third party, the Delegation to Member Service Provider letter must be sent
as well. In most cases, MasterCard prefers that Security Officers be registered
via a face-to-face meeting. If this is not possible, we will require the registration
forms to be notarized or validated in some similar fashion.

Crypto Self-Test Tool (CSTT)—The Key Management team will provide

the registered security officers with instructions to download this in house
application from MasterCard OnLine. This tool is required to facilitate the key
exchange.

Testing Requirements
There are two separate testing efforts involved in the implementation of this
service: authorization testing and testing the AAV validation.

Authorization Testing
Upon approval of the enrollment forms, issuers will be contacted by the
appropriate Customer Implementation Services team within MasterCard to
coordinate the authorization testing process. Authorization testing in support of
the AAV Validation service is required in all regions. Refer to the appropriate
specification manual for applicable test cases. Testing is performed via the
MasterCard credit and debit simulators only. Online testing is not available.

©2005–2011 MasterCard. Proprietary. All rights reserved.

G-2 2 December 2011 • MasterCard SecureCode—Issuer Implementation Guide
 AAV Validation Service Implementation Process
AAV Validation Service in Production

Authorization testing can be performed at any point during the implementation

and is not dependent on other implementation events. The recommendation is
to schedule this early so that any issues can be worked through while other
implementation activities are progressing. The Customer Implementation
Services team will notify the SecureCode test team when testing has successfully
completed.

AAV Key Validation

This is the final stage of the implementation process before moving forward
with enabling the service in a production environment. After the successful
exchange of keys, the issuer must be prepared to generate at least one AAV per
BIN using the production keys in order to perform the validation of the AAV
keys exchanged. The Key Management team will notify the SecureCode test
team when this has been completed.

AAV Validation Service in Production

Upon successful validation of the AAV keys, coordination of the production
implementation can begin.

Key Management Team—The Key management team will work with the
Network Operations team to have the appropriate keys loaded into the
MasterCard production network. This takes approximately three business days.

Customer Implementation Services Project Manager—The Customer

Implementation Services Project Manager will work directly with the member to
define a “live” date. Issuers must coordinate any internal authorization changes
with the live date of the AAV Validation service. Minimum of 10 days notice
required for implementing a “live” day after the keys have been loaded.

©2005–2011 MasterCard. Proprietary. All rights reserved.

MasterCard SecureCode—Issuer Implementation Guide • 2 December 2011 G-3