1. Guaranteed Payments for E-Commerce Transactions
A New, Universal Solution from MasterCard
Mark Patrick
Vice President - Interactive Services
MasterCard International
MasterCard Proprietary

2. Increased Consumer Confidence and Spending
Guaranteed Payments
Increased Consumer Confidence and Spending
Security in Cross-Border Transactions
MasterCard Proprietary

3. E-Commerce Market Challenges
Consumers
Fear of fraud remains barrier to converting online browsers to online shoppers
Consumer Internet purchases generally restricted to domestic marketplaces

4. E-Commerce Market Challenges
Issuers
Mounting costs from processing online chargeback disputes
Higher decline rates for online transactions
Lessened revenue
Consumer confidence in online channel affected by stream of fraud reports in media

5. E-Commerce Market Challenges
Merchants and Acquirers
No guarantee of payment for merchant
Online chargebacks growing
Bears all risk for non-signature based transactions
Online fraud losses mounting
Lack of consistent mechanism to authenticate the buyer to the seller
Privacy laws restrict use of authentication tools
High accountholder decline rate – limits activity, especially for cross-border transactions

6. Findings
As a result, merchant chargeback expenses for online transactions are increasing
“Reason code 37” chargebacks now represent as much as 84%* of all e-commerce chargebacks
Chargeback
Purchase
*Source: INET Reports, 4th Quarter 2000

7. Introducing...
UCAF
SPA

8. Consumer Rationale
“Secure” is reassuring and strong.
“Code” is secret, private and stronger than “password”

9. SecureCode Objective Fully Guaranteed Transactions
Proposal is to eliminate RC 37 “Fraudulent Transaction - No Cardholder Authorization” chargebacks for any electronic/mobile commerce transaction that is processed and authorized in accordance with all of the elements of the guaranteed transaction model by both the issuer and the merchant/acquirer

10. Why Fully Guaranteed Transactions
 Extend the MasterCard guarantee of payment from the physical POS to new points of interaction
 Increase consumer confidence in new channels
 Improve acceptance and preference for MasterCard at remote points of interaction
 Reduce chargebacks and fraud
 Increase overall electronic/mobile commerce transactions, approval rates, and GDV

11. MasterCard SecureCode Components

12. Universal Cardholder Authentication Field (UCAFTM)
Objective:
Collect and transport an indisputable electronic receipt that binds the accountholder to a unique transaction and provides the basis for a guaranteed transaction

13. UCAF Solution Overview
Establishes one interoperable and standardized data transport infrastructure for all secure online and wireless payments, including both credit and debit
Offers a universal method of collecting accountholder authentication data at the merchant virtual point-of-sale
Provides the infrastructure for transporting accountholder authentication data from merchants, acquirers, networks to an issuer

14. UCAF Solution Overview
UCAF consists of two components, a series of discreet, hidden fields:
UCAF Data Infrastructure
UCAF Authentication Data Field
Interacts with a wide variety of issuer security schemes including, MasterCard’s Secure Payment Application (SPA)

15. UCAF Data Infrastructure
Merchant Name
Card Acceptor City
Card Acceptor State / Country Code
Currency Code
Sale Amount
Merchant Transaction Stamp
UCAF Authentication Data Field
UCAF Enabled
UCAF Brand
Carries security token
The UCAF Authentication Data Field is first among equals in the UCAF data infrastructure

16. Acquirer UCAF Components
Merchant point of sale (POS) interface passes the UCAF authentication data
Acquirer systems collect and pass UCAF data
Acquirer systems must support DE48, the expanded sub-element 42 and the new sub-element 43
Acquirer
Issuer
Merchant
UCAF data
(unaltered)
UCAF data (unaltered)

17. The UCAF Environment UCAF Environment Accountholder Merchant Issuer
Present, Collect,
Pass
Merchant Name
Card Acceptor City
Card Acceptor State/Country Code
Currency Code
Sale Amount
MTS (optional)
UCAF Authentication Data Field
Account Number
Expiration Date
CVC2
UCAF Enabled
UCAF Brand
Accountholder shops with an Issuer defined security solution that uses the UCAF structure
Issuer
Acquirer
Issuer-Defined
Security Token carried via
UCAF Authentication Data Field
Issuer validates and authorizes
defined security token

18. Merchant Responsibilities
Update website to include UCAF hidden data fields
Evaluate server capabilities
Contact your transaction processor to arrange UCAF support

20. MasterCard SPA Using the UCAF Infrastructure

21. What is SPA? Secure Payment Application
MasterCard’s preferred issuer-based security scheme for remote transactions
Utilizes the UCAF data transport infrastructure to provide an effective online consumer authentication tool

22. What is SPA?
SPA defines the protocols, messages, message formats, and data requirements for an overall issuer-centric remote security solution
Based on MasterCard IPR, SPA is licensed separately to vendors as well as end users (members) to work in conjunction with existing infrastructures, like wallets or pseudo account schemes
Vendor solutions will go through a SPA and UCAF certification process

23. How Does SPA Work?
An issuer’s SPA enabled server generates a unique security token—similar to a signed electronic receipt—called an Accountholder Authentication Value or AAV
It populates the UCAF infrastructure at the merchant pay page and is transported back to the issuer for verification during authorization
SPA enabled transactions can be recognized through the use of unique control bytes assigned and managed by MasterCard

24. The SecureCode Environment
SPA Environment
UCAF Environment
1) Accountholder fills out Merchant Pay Page
2) SPA solution detects hidden fields on merchant payment page
3) SPA solution launches
5) SPA solution populates hidden UCAF data field with AAV
6) AAV passed unaltered via UCAF data field to Acquirer
Accountholder with SPA solution
Merchant
4) Accountholder is verified by Issuer SPA server
Issuer with SPA server
Acquirer
-Generate and store AAV data
-Validate AAV during
authorization
SPA Server
8) AAV validated by SPA server
7) Acquirer passes AAV via UCAF data field unaltered to payment network

25. *********
At this point, you’ve submitted your information and it has been recognized that you have registered for the MasterCard SecureCode service so this dialog box would pop-up asking you for your User Name and SecureCode (the one that you created when you registered for the service).
You type in your User Name and SecureCode and confirm that the information is correct, then you click on the confirm button to confirm your identity for this purchase.

26. MasterCard Solutions for Issuer and Acquirers

27. Solutions For Issuers - Options
Build an in-house solution for SPA and 3D Secure
Outsource to a third party
“Verified by Visa”
MasterCard’s Managed Service for SPA & 3D
Others: e.g. Cyota

28. Solutions For Issuers - Options (cont.)
Build an in-house solution for SPA and 3D Secure
Difficult to build the business case
Uncertain environment
Expensive to maintain
More control

29. Solutions For Issuers - Options (cont.)
Outsource to a third party
“Verified by Visa”
MasterCard’s Managed Service for SPA & 3D
Others like: e.g. Cyota
MasterCard’s Managed Service provides a local solution for all your cardholders
Very cost effective

30. Objectives of Managed Service
Remove financial barriers to implementing SPA
- improved business case
- significantly reduces chargeback costs
Provide flexible platform for bank branded services
Support multiple authentication methods as required
- SPA
- 3D-Secure
Complimentary to MIGS service

31. Authentication Engine Cardholder Access Method
Multiple Standards - One Issuer Solution
Maestro Module
3-D Secure Module
SPA Module
Future Protocols
ActiveAccess
Authentication Engine
Cardholder Applet
Cardholder Browser
Cardholder Mobile
Device
Cardholder Plug-in
(Chip)
Cardholder Access Method

32. Issuer’s Datacenter MasterCard APC AAV Verification Module HSM
MIP/ VAP
Issuer Authorization Host
MIP/ VAP
BankNet/VisaNet
Acquirer Host/ Switch/ Gateway
Issuer’s Existing Card Management System
Cardholder Data
Internet Payment Gateway
Data Upload
Module
MasterCard APC
Batch
Merchant Web Storefront
Cardholder Authentication Data
MPI
UCAF
Visa Directory Server
ACTIVE ACCESS SERVER
Issuer Administration and Registration
3D Secure Module
(ACS)
SPA Applet
Download Server
Cardholder Enrollment
SPA Module
(AAV generation)
HSM
Download
Enrollment
Browser
Browser
SPA Applet
Enrollment/ Download
Shopping

33. Solutions for Acquirers
MIGS
MIGS is a turn key payment gateway, that significantly reduces the complexity and costs of acquiring, enabling, supporting and processing for Card Not Present merchants.
MIGS leverages the Bank’s existing transaction processing connectivity to MasterCard’s Banknet® Global Network.

34. Why MIGS for the Member Bank ?
Banks lack business case yet face losing Merchants
MIGS takes investment risk away from Member Bank
Outsourcing with benefits of in-house and more
MIGS is quicker to market (2 months instead of 12)
Much lower cost and off balance sheet!
MIGS is a high value added service…
from MasterCard to its Member Banks

35. Merchant/Enterprise/
MIGS Architecture
Merchant/Enterprise/
Portal Server(s)
Online Store
E-commerce
M-commerce
T-commerce
Call Center
Telesales
IVR
Electronic Bill
Presentment
Business Systems
ERP
CRM
E-Procurement
Portal
MIGS
Authenticated
with Digital
Certificate
BANKNET
Internet
&
Private
Banks
and
Card
Schemes
Digital Order (DO)
Integrated MIGS Payment Solution
Digital Receipt (DR)
Merchant
Administration
and Reporting
Subsequent Transactions
Capture / Refund
Reconciliation
Enquiries & Reports

36. MIGS - Switch to Issuer Acquirer Issuer 5 2 1 4 3 MERCHANT RSC
WEB Site
Acquirer
MIGS
Payment Server
RSC 5 2 1 4 3
Issuer
Cardholder

37. MasterCard Guaranteed Payment Milestones

38. Implementation Timeline
1 April 2002
 Issuers and Acquirers Support System Requirements
1 November 2002
 Liability shift for full UCAF authorizations
Rules changes for Chargeback Reason Code 37 become effective for electronic and mobile commerce fully guaranteed transactions
No liability shift for issuers that do not populate the UCAF field
1 April 2003
 Proposed Asia Pacific liability shift
 Determine position on global liability shift
WHERE ARE WE TODAY WITH THE MASTERCARD RPPS PRESENTMENT SERVICE?
THE PROGRAM WAS ANNOUNCED LAST MARCH AND LAUNCHED IN SEPTEMBER. WE’RE WORKING WITH MULTIPLE CSPS AND BSPS WHILE CONTINUING TO ROLL OUT THE SERVICE NATIONWIDE. AND WE’RE SEEING SOME OF THE EXPERIENCES WE HAD DURING OUR PAYMENT AND DMP LAUNCHES. NAMELY, BSPS AND CSPS ALL SEEM TO UNDERSTAND THE EFFICIENCIES AND ADVANTAGES OF ELECTRONIC BILL PRESENTMENT, BUT THEY’VE BEEN SOMEWHAT SLOW TO IMPLEMENT THE ACTUAL CAPABILITY.
EVERYONE REPEATS THE SAME MANTRA - “WE’RE WAITING TILL YOU CAN GIVE US MORE BILLERS AND MORE VOLUME.”
WELL, THIS IS A NEAT CATCH-22, BECAUSE THEY ARE THE VOLUME.
SO OUR RESPONSE—AND OUR BATTLE CRY FOR SUCCESS IN 2001—IS “DEVELOP, CONNECT, AND LAUNCH.”
WE BELIEVE THAT THE HISTORY LESSONS ON THE PAYMENT SIDE WILL HELP ACCELERATE GROWTH FOR BILL PRESENTMENT. WE SAW THE SAME INITIAL HESITATION IN PAYMENTS, BUT WE ALSO SAW AN EXPLOSION OF VOLUME ONCE BOTHS SIDES COMMITTED TO “DEVELOP AND CONNECT.”
WE DON’T EXPECT TO WAIT NEAR AS LONG FOR THE PRESENTMENT EXPLOSION, AND INDUSTRY PROJECTIONS CERTAINLY SUPPORT THIS VIEWPOINT. MASTERCARD RPPS IS READY.
(BACK UP ONLY)
GARTNER RESEARCH SEES 25% OF ALL BILLS BEING PRESENTED ELECTRONICALLY BY JUPITER RESEARCH PREDICTS A JUMP OF NEARLY 550% OVER THE NEXT TWO YEARS.
MasterCard Proprietary