Ensuring the Safety & Security of Payments

18
Ensuring the Safety & Security of Payments Faster Payments Symposium August 4, 2015

Transcript of Ensuring the Safety & Security of Payments

Page 1: Ensuring the Safety & Security of Payments

Ensuring the Safety & Security of Payments

Faster Payments Symposium

August 4, 2015

Page 2: Ensuring the Safety & Security of Payments

Problem Statement: The proliferation of live consumer account credentials

TCH CONFIDENTIAL 2

Bank issues physical card

Plastic at point of sale

Ecommerce at checkout

Web bill payment

Mobile Apps

Mobile Wallet

Payment Aggregators

Future…

Page 3: Ensuring the Safety & Security of Payments

Large scale data breaches brought payments security into the public consciousness

TCH CONFIDENTIAL 3

2014 was a bad year for credit card hacks, hitting companies in very different industries

Reputational impact - Combined effect of

several big breaches created an environment of

concern for anyone holding credit cards on file

Financial impact - Stolen credit card

information has a real cost to issuers which is

typically then borne by the entity that was

hacked

Consumer impact - Consumers have to update

billers with new card information which can be

time consuming

Retailers, banks and consumers agreed that additional securities are needed

Page 4: Ensuring the Safety & Security of Payments

EMV and tokenization work together to create vastly greater protections against credit card fraud

TCH CONFIDENTIAL 4

EMV has been in use outside of the U.S. for decades. Tokenization is a newer concept but governed by the same organization as EMV cards, so the two efforts are cross compatible

Protects against card-not-present fraud-

Tokenization replaces real card account

numbers with different digits, protecting cards

on file with different merchants

Tokens have limitations on use – Tokens

prevent fraud by limiting their use to a single

merchant or mobile wallet. Steal them and

they aren’t useful anywhere else

Know your customer – Tokens also rely on a

process known as ID&V or identification and

verification that validates the cardholder is

involved in the creation request for a token

Protects against card-present fraud – EMV

(a.k.a. chip and PIN), secures against stolen

card numbers being loaded onto a fake card

and then used at a retailer

Cryptographic protection – An EMV chip

creates a dynamic cryptogram for each

transaction that prevents stolen account

information from being used without the

presence of the correct chip

Multi-factor – Use of the chip (something you

have), and PIN (something you know) prevents

thieves from using stolen cards

EMV Tokenization

Page 5: Ensuring the Safety & Security of Payments

Tokenization definition and attributes

TCH CONFIDENTIAL 5

Typical Attributes of Payment Tokens Format-preserving for legacy compatibility

Either “dynamic” or “static”; if static, may be combined with a cryptogram

Restricted in scope / not “general purpose”

Can be used live to authorize / clear

transactions

Token Components Consists of 15-19 digits + expiration date

Domain Restrictions limit the use of the

token

Cryptogram that is unique to each

transaction

Tokenization

Substitutes a limited-use random number (secure digital token) for customer’s account numbers so that the sensitive information remains safe. Even if compromised, the token is of limited or no use to cybercriminals

Token Vaults

Bank (or multi-bank) vaults create tokens, perform customer authentication and provision tokens to digital wallets or directories

Page 6: Ensuring the Safety & Security of Payments

Major tokenization use case overview

TCH CONFIDENTIAL 6

Mobile POS ECommerce

DDA/ACH EMV Cards (potential)

• Mobile has been industry

focus and primary use case at this time

• Secures mobile wallets (NFC HCE, NFC SE, QR, etc.) by using a token instead of PAN on device

• User experience defined by wallet provider, meeting bank ID&V and security requirements

• Use cases range from

traditional card on file to ‘in App’

• User experience defined by merchant or digital wallet provider, meeting bank ID&V and security requirements

• Tokenized DDA account

information masks transaction initiated via ACH

• EMV and card tokens could likely shift fraud to ACH

• Increased usage of ACH for one-time payments (POS, WEB) highlights risks of misuse

• Reduce breach risk of mass account on file databases

• Chip on EMV card stores

token instead of PAN

• Enables fully tokenized POS transactions, addressing retailer breach concerns

• EMVCo evaluating opportunity

• Assessment of residual risk post EMV rollout to determine attractiveness

DDA tokenization is part of the roadmap, as a fast follow to card based payments

Page 7: Ensuring the Safety & Security of Payments

Secure Token Exchange replaces live credentials with digital tokens consistent with the

EMVCo framework

TCH CONFIDENTIAL 7

Merchant

No access to customer bank account information

Access to customer bank account information

*token / account exchange

Token Service

Provider Token Vault

eW

mW

Payment with Token Bank Issuer

Customer Authentication (ID&V)

Token Provisioning)

ID&V

Acquirer Card

Networks Consumer

Page 8: Ensuring the Safety & Security of Payments

Tokenization benefits all parties in the eco-system

TCH CONFIDENTIAL 8

Sensitive account information is static

Customers provide live bank data to retailers, wallets, alternative payment providers, aggregators, others

Fraud risk increasing as cards upgrade to EMV, and as e-commerce and mobile grow

Confusing and complicated process to maintain and update consumer information across multiple providers when a card is lost, stolen or expired

Today

Customer bank data securely held behind bank firewalls

Consumers don’t need to provide sensitive information to multiple providers

Lower fraud potential in event of data breach or lost/stolen device

Single contact point to update and maintain consumer information

No change in consumer behavior at POS

With Tokenization

U.S. has opportunity to lead the world by rolling out tokenization in conjunction with EMV to protect against card present and card not present fraud

Page 9: Ensuring the Safety & Security of Payments

Six Safety & Soundness Principles guide TCH token efforts

TCH CONFIDENTIAL 9

STANDARDS-BASED: Establishes clearly defined standards Aligns with regulatory environment and avoids

overlap with existing standards Considers and respects int'l standards as a means of

facilitating interoperability

OPEN: Allows for different business models Fosters innovation Ensures competition among market participants

(e.g., vaulting)

SUSTAINABLE: Creates a path forward to support long-term viability Adapts over time as technology evolves Allows for economically viable business models that

accelerate adoption

SAFE & SECURE: Protects confidential personal, financial, and

transactional information within the mobile and e-commerce payments ecosystem

Facilitates secure interactions

INITIAL FOCUS ON HIGH-RISK USE CASES: Mobile and e-Commerce Supports exception flows, lifecycle management Supports multiple form factors (e.g., NFC, QR codes) Extension to ACH/DDA based payments

RESPONSIVE TO END USER AND MERCHANT NEEDS: Provides for ease of use, speed, availability, security,

transparency, choice and consistency for users

1.

2.

3.

4.

5.

6.

Page 10: Ensuring the Safety & Security of Payments

Token eco-system

TCH CONFIDENTIAL 10

The token ecosystem is comprised of the same general players as regular card transactions, with the additional roles of token requestor and token service provider

Entity Description

Token Vault The token vault is responsible for token creation, maintaining token-to-PAN mapping, and performing detokenization

Token Service Provider (TSP)

The token service provider is the all-encompassing term that includes the functions of the token vault, but also provides application of security controls, provisioning, lifecycle management, and token requester registry services

Token Requestor Entity that requests to receive a token instead of using and storing real account data for payments. Can be digital wallets, merchants, or acquirers, payment gateways etc. on behalf of merchants

Cardholder Initiates the creation of a token by adding their account into a tokenized environment such as a mobile wallet or token enabled e-commerce merchant

Card Issuer Financial institution that issues the payment account. Ultimately responsible for customer authentication (ID&V) and token issuance either through their own TSP or a 3rd party.

Merchant Can act as a token requestor (e.g., card-on-file e-commerce) or simply as a recipient of a token based transaction (e.g., Apple Pay)

Acquirer Acquirers process all transactions as they do today including authorization, capture, clearing and exception processing. Additional fields are required for token conveyance

Payment Network Continue to facilitate authorization and settlement, and provide optional vault and TSP services to issuers

Issuer Processor Receive additional token related fields from payment network, call-out to TSP for detokenization, and perform ID&V on behalf of issuers

Ne

w E

nti

tie

s Ex

isti

ng

Enti

ties

Page 11: Ensuring the Safety & Security of Payments

Key token related components

TCH CONFIDENTIAL 11

Tokenization uses several unique terms that are important to understand

Terminology Definition

Cryptogram A transaction unique value that is generated via an algorithm using transactional information and cryptographic keys. The cryptogram is generated by the token requestor and verified by the token service provider. The algorithm used is defined by respective card networks

Domain Restriction A set of parameters established as part of token issuance that limits token usage to a specific wallet, entry mode/channel, merchant, merchant category, and/or dollar limits and velocity of transactions.

Identification & Verification (ID&V)

Method(s) used for issuers to authenticate the end-user (e.g., fingerprint on device, challenge questions, password entry etc.)

Token Assurance Level A value between 0-99 assigned by the TSP using issuer specified rules that conveys the level of confidence in the customer authentication performed during token provisioning, reflecting the type of ID&V that was performed and who performed it.

Page 12: Ensuring the Safety & Security of Payments

Secure Token Exchange walk-through

TCH CONFIDENTIAL 12

Exchanges PAN and expiration date for format preserving digital numbers unseen by the consumer

Token

Cryptogram

Contains an algorithm that adds a dynamic component to the token and makes the token useless without proper “keys”

Token Definition Token Management Infrastructure

The token vault and TSP are designed to comply with the specs from previous two stages

Token Data Flow

• Account (PAN) to token mapping • Provisioning management • Lifecycle management • Domain Control • Cryptogram Validation • Check Eligibility • ID&V

Includes both provisioning and transactional data flows which need new messages between entities

Determines token format, additional security layers and new token transaction fields

Primary Functions Provisioning Flow

• Token request – messages between wallet/merchant and TSP

• ID&V – level of assurance that request is valid

• Token delivery – messages to load token into wallet

Transaction Flow

• Cryptogram created at time of purchase

• Detokenization request by network

BIN Digits Check Digit

Page 13: Ensuring the Safety & Security of Payments

Token cryptogram characteristics

TCH CONFIDENTIAL 13

Format preserving – 16 digits for Visa and MasterCard, works with existing systems without modification

Token BIN – Tokens are issued from special BINs which identify the presence of a token to all parties. The token BIN contains all of the attributes of the original PAN: e.g., begins with 4 for Visa, 5 for MasterCard, indicates debit vs. credit, routing instructions etc. • Due to BIN exhaustion, networks have

subdivided some BINs changing the structure from 6+9+1 to 8+7+1 with eight digits representing the “token BIN range” instead of 6

Use case specific – Cryptograms are not used in every token use case, such as lower risk use cases

Dynamic Component– If the token itself remains static, then the cryptogram adds the dynamic component that dissuades fraud

BIN Digits Check Digit

Toke

n

PA

N

6 + 9 1 +

Token Characteristics Cryptogram Characteristics

EMV Compatible – Cryptograms used for mobile payments use rules very similar to cryptograms used in EMV card transactions

Required Fields – • Token PAN • Token Expiration (which can be different

from the PAN expiration)

Cryptogram is a transaction-unique value calculated at time of purchase; designed to validate authorized use of token

Crypto Keys – Each network can establish a proprietary cryptographic algorithm that uses different transactional information and requires corresponding keys

Page 14: Ensuring the Safety & Security of Payments

Secure Token Exchange provisioning

TCH CONFIDENTIAL 14

When consumers sign up for a digital wallet directly, this generates a token request that must be validated by the Issuer before a token can be used

Token Requestor

Issuer / Processor

STE™

Request

Response

Optional Fields (O)

Legend

• Token Requestor ID • PAN, Exp. Date, CVV • Token Assurance Data • Requested TAL (O)

• Token (if approved or pending)

• Eligibility Status • Token Assurance Level

• Additional ID&V Method (if applicable)

• Card Art + Description • Terms and Conditions

2

5 4

3

2 3

• Eligibility Status • Additional ID&V (if applicable)

5 4

• Token Requestor ID • PAN, Exp. Date, CVV • Token Assurance Data • Requested TAL (O)

Possible Eligibility Statuses:

• Approved – The token is provided to the Token Requestor in an active state

• Pending – The token is sent to the Token Requestor, but is inactive until the cardholder takes additional verification steps

• Denied – A token is not returned to the Token Requestor and the cardholder is informed to contact their financial institution for more information

1

6

• PAN, Exp. Date, CVV

1

6

Provisioning

Page 15: Ensuring the Safety & Security of Payments

Secure Token Exchange provisioning – Additional Verification

TCH CONFIDENTIAL 15

Issuers can use different methods of additional ID&V including out of band authentication, banking application or 1-800 number to resolve a “pending” yellow-path token

Provisioning

Token Requestor

STE™

Out of Band Authentication: 1. Consumer selects SMS, Email or other out of band method to

provide additional verification 2. Token Requestor informs STE which option was chosen 3. STE generates a verification code and sends to device or email

(alternatively, issuer can generate code and send to device) 4. Consumer enters code 5. Token Requestor passes along entered code 6. STE validates code entry and sends Token Requestor

confirmation or denial 7. Token Requestor sends device approval messages or

additional steps for consumer to contact Issuer

1 4

7

2 5

6

3

Bank Application/ Call Center

Token Requestor

STE™

3 2 1

4

Banking Application/Call Center 1. Consumer selects bank application or 1-800 number to

provide additional verification 2. Banking App or Call Center informs STE the outcome of the

verification challenge 3. STE informs Digital Wallet if the token is approved or denied 4. Token Requestor moves token to live status if approved

Bank Application/ Call Center

-or-

Page 16: Ensuring the Safety & Security of Payments

Secure Token Exchange payment transaction flow: Mobile point-of-sale, Pass-Through model

TCH CONFIDENTIAL 16

Net new token fields are shown, all other data is passed as usual

Transactions

Mobile Wallet

Merchant Acquirer Payment Network

Issuer / Processor

1 2 3 4

7 8 9 10

Auth Request

Auth Response

BAU Data Fields

Token Data in Current Fields

Optional Fields

*

** New Data Fields ***

(O)

Legend

STE™

5

6

• Token ** • Token Exp. Date ** • Token Requestor ID*** • Token Cryptogram **

• Token ** • Token Exp. Date ** • Token Requestor ID (O)*** • Token Cryptogram ** • POS Entry Mode *

1 2 3 4 5

• Token ** • Token Exp. Date ** • Token Requestor ID*** • POS Entry Mode • PAN* • PAN Exp. Date * • Token Assurance Data (O) *** • Token Assurance Level ***

• Token ** • Token Requestor ID (O) *** • POS Entry Mode • PAN* • Token Assurance Level *** • PAN Product ID (O) **

• Token ** • Token Assurance Level *** • PAN Product ID (O) ** • Last 4 digits of PAN***

8 9 7 6

• Token ** • Token Assurance Level *** • Last 4 digits of PAN***

Page 17: Ensuring the Safety & Security of Payments

Lifecycle Management Functions

TCH CONFIDENTIAL 17

Issuer tokens allow for several important lifecycle management functions

Transactions

STE™

Cardholder Initiated: • Suspend • Resume • Delete

Issuer Initiated: • Suspend • Resume • Delete • Update • Transaction History

Functions Definition

Suspend A request to freeze the tokens in the digital wallet, e.g., mobile device is lost

Resume The freeze placed on tokens by a suspend request is lifted and tokens are once again live. A resume request can only be issued by the party who originally suspended the token

Delete Tokens can be removed from the wallet at any time by a request for deletion

Update An Issuer request to update various fields associated with a token, including, expiration date of token or PAN, change to underlying PAN, domain restriction change, change to attributes of PAN, token assurance level, or a change to the last four digits of PAN

Transaction History (optional)

Provides information on past purchases to the digital wallet. Contains location, date, amount and merchant information

Page 18: Ensuring the Safety & Security of Payments

The DDA Token working group is focusing on adapting card token standards into a

tokenization solution for DDA-based transactions, beginning with ACH payments

Workshop Deliverables

Follow-on efforts

Generate a DDA Token framework to include:

– DDA token scope and definition

– Corresponding data elements

– Flows for provisioning, transactions and

lifecycle management

Generate an industry business case to

evaluate the opportunity

Evaluate potential NACHA rule changes

needed to support token formats and

drive ubiquity

Engagement with the Federal Reserve RPO

to generate alignment

Develop a timeline for implementation

Guiding Principles

DDA Tokenization applies to both current ACH as well

Same-Day and/or Real-Time transactions

Consistency with mobile/card tokenization, with

differences to account for new requirements and use

cases for ACH

Minimize change to ACH formats and processing flows

Support for merchant / digital wallet use cases where

both card and ACH tender options are tokenized

TCH CONFIDENTIAL 18