Ensuring the Safety & Security of Payments
Transcript of Ensuring the Safety & Security of Payments
Ensuring the Safety & Security of Payments
Faster Payments Symposium
August 4, 2015
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…
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
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
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
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
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
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
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.
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
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.
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
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
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
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-
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***
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
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