Guaranteed Payments for ECommerce Transactions A New Universal

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

Guaranteed Payments Increased Consumer Confidence and Spending Security in Cross-Border Transactions Master. Card Proprietary

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

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

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

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, 4 th Quarter 2000 6

Introducing. . . UCAF SPA

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

Secure. Code 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 9

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

Master. Card Secure. Code Components

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

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 13

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, Master. Card’s Secure Payment Application (SPA) 14

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

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 DE 48, the expanded subelement 42 and the new sub-element 43 Acquirer Issuer UCAF data (unaltered) Merchant UCAF data (unaltered) 16

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

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

19

Master. Card SPA Using the UCAF Infrastructure

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

What is SPA? • SPA defines the protocols, message formats, and data requirements for an overall issuer-centric remote security solution • Based on Master. Card 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 22

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 Master. Card 23

The Secure. Code Environment SPA Environment Accountholder with SPA solution UCAF Environment Merchant 1) Accountholder fills out Merchant Pay Page 2) SPA solution detects hidden fields on merchant payment page 3) SPA solution launches 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 5) SPA solution populates hidden UCAF data field with AAV 6) AAV passed unaltered via UCAF data field to Acquirer 7) Acquirer passes AAV via UCAF data field unaltered to payment network 24

Master. Card Solutions for Issuer and Acquirers

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

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

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

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 - 3 D-Secure Complimentary to MIGS service 30

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

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

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 Master. Card’s Banknet® Global Network. 33

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 Master. Card to its Member Banks 34

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

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

Master. Card Guaranteed Payment Milestones

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 1 April 2003 Determine position on global liability shift Master. Card Proprietary

39