CSCIP Module 5

Module 6/P: Smart Card Usage Models – Payments and Financial Transactions

Smart Card Alliance Certified Smart Card Industry Professional Accreditation Program

About the Smart Card Alliance

The Smart Card Alliance is a not-for-profit, multi-industry association working to stimulate the understanding, adoption, use and widespread application of smart card technology. Through specific projects such as education programs, market research, advocacy, industry relations and open forums, the Alliance keeps its members connected to industry leaders and innovative thought. The Alliance is the single industry voice for smart cards, leading industry discussion on the impact and value of smart cards in the U.S. and Latin America. For more information please visit http://www.smartcardalliance.org.

Important note: The CSCIP training modules are only available to LEAP members who have applied and paid for CSCIP certification. The modules are for CSCIP applicants ONLY for use in preparing for the CSCIP exam. These documents may be downloaded and printed by the CSCIP applicant. Further reproduction or distribution of these modules in any form is forbidden.

Copyright © 2015 Smart Card Alliance, Inc. All rights reserved. Reproduction or distribution of this publication in any form is forbidden without prior permission from the Smart Card Alliance. The Smart Card Alliance has used best efforts to ensure, but cannot guarantee, that the information described in this report is accurate as of the publication date. The Smart Card Alliance disclaims all warranties as to the accuracy, completeness or adequacy of information in this report.

TABLE OF CONTENTS 1 INTRODUCTION ...... 6 2 SMART CARD MARKET DRIVERS AND BENEFITS FOR PAYMENTS AND FINANCIAL TRANSACTIONS ...... 7 2.1 REDUCING FRAUD AND ENHANCING SECURITY ...... 8 2.2 ENHANCING CONSUMER CONVENIENCE AND CONFIDENCE ...... 8 2.3 ENHANCING THE BUSINESS CASE WITH MULTIPLE APPLICATIONS ...... 8 2.4 IMPROVING EFFICIENCY AND INCREASING SALES VOLUME AT THE MERCHANT POS ...... 9 2.5 SUPPORTING INNOVATION AND DIFFERENTIATION ...... 9 3 BANK CARD PAYMENTS ...... 10 3.1 BANK CARD TECHNOLOGY AND PROCESSING: MAGNETIC STRIPE CARDS ...... 11 3.2 BANK CARD TECHNOLOGY AND PROCESSING: SMART CARDS ...... 12 3.2.1 EMV ...... 13 3.2.2 Contactless Payments ...... 18 4 EMV ...... 19 4.1 EMV SECURITY ...... 20 4.1.1 Card Authentication Methods (CAM) ...... 20 4.1.2 Cardholder Verification Methods (CVM) ...... 21 4.1.3 Transaction Authorization ...... 22 4.1.4 EMV Use of Symmetric and Asymmetric Cryptography ...... 23 4.2 EMV TRANSACTION FRAMEWORK ...... 24 4.3 EMV CHIP SOFTWARE AND DATA ...... 26 4.3.1 EMV Chip Applications and AIDs ...... 27 4.3.2 EMV Chip Data ...... 27 4.4 EMV CHANGES TO THE MESSAGING INFRASTRUCTURE ...... 28 4.5 EMV MIGRATION OPTIONS ...... 30 4.5.1 Card Interface Options ...... 31 4.5.2 Card Authentication and Transaction Authorization Options ...... 32 4.5.3 Cardholder Verification ...... 32 4.5.4 Hybrid Options ...... 32 4.5.5 EMV Infrastructure and Migration ...... 33 4.6 CARD ISSUER MIGRATION CONSIDERATIONS ...... 33 4.6.1 Card Interface ...... 33 4.6.2 Offline PIN vs. Online PIN...... 33 4.6.3 Personalization System ...... 34 4.6.4 Host System ...... 34 4.6.5 Transaction Authorization Process ...... 35 4.6.6 Summary ...... 35 4.7 PAYMENTS ACQUIRER/PROCESSOR CONSIDERATIONS ...... 37 4.7.1 Contactless MSD ...... 37 4.7.2 Contactless EMV ...... 37 4.7.3 Contact EMV with Signature or PIN...... 38 4.7.4 Summary ...... 38 4.8 POS TERMINAL AND MERCHANT POS SYSTEM CONSIDERATIONS ...... 39 4.8.1 Hardware Support...... 39 4.8.2 Software Support ...... 40 4.8.3 EMV and Brand Certification ...... 41 4.8.4 Transaction Messaging Support ...... 42 4.8.5 Terminal Upgrade Capabilities and Plans ...... 43 4.8.6 Summary ...... 43

4.9 U.S. EMV DEBIT ...... 45 4.10 ATM CONSIDERATIONS ...... 46 4.10.1 ATM Hardware ...... 46 4.10.2 ATM Software ...... 46 4.10.3 Certifications ...... 47 4.10.4 Terminal Upgrade Capabilities and Plans ...... 48 4.10.5 Summary ...... 48 4.11 EMV AND NFC MOBILE CONTACTLESS PAYMENTS ...... 49 5 CONTACTLESS BANK CARD PAYMENT ...... 51 5.1.1 EMV Contactless ...... 51 5.1.2 Contactless Credit/Debit Payment in the U.S...... 52 5.1.3 Contactless Benefits ...... 53 5.1.4 Developments in Contactless Payments ...... 54 6 MOBILE PAYMENTS ...... 55 6.1 CHARACTERISTICS AND TYPES OF MOBILE PAYMENTS ...... 55 6.1.1 P2P Mobile Payment ...... 56 6.1.2 Remote Mobile Payment ...... 57 6.1.3 Proximity Mobile Payment ...... 58 6.2 NFC-ENABLED MOBILE PAYMENTS ...... 59 6.2.1 Secure Element-Based NFC Mobile Payments ...... 60 6.2.2 Host Card Emulation-Based NFC-Enabled Mobile Payments ...... 73 6.2.3 NFC and EMV ...... 79 6.3 COMPARISON OF MOBILE PAYMENT APPROACHES ...... 79 6.3.1 Review of Mobile Payment Approaches ...... 80 6.3.2 Evaluation Criteria ...... 84 6.3.3 Comparison of Approaches to Mobile Payment ...... 85 6.3.4 Summary ...... 86 7 SECURE REMOTE TRANSACTIONS: RETAIL E-COMMERCE ...... 87 7.1 AUTHENTICATION METHODS ...... 88 7.1.1 Device Authentication ...... 89 7.1.2 One-Time Password ...... 89 7.1.3 Randomized PIN Pad ...... 90 7.1.4 Biometrics ...... 91 7.2 FRAUD TOOLS ...... 92 7.2.1 Proprietary Data/Transactional Data ...... 92 7.2.2 Validation Services ...... 92 7.3 3-D SECURE ...... 93 7.4 TOKENIZATION ...... 94 7.5 SUMMARY ...... 94 8 SECURITY LAYERS PROTECTING THE PAYMENTS INFRASTRUCTURE: EMV, ENCRYPTION AND TOKENIZATION ...... 96 8.1 EMV TECHNOLOGY ...... 96 8.2 TRANSACTION DATA ENCRYPTION ...... 97 8.3 TOKENIZATION ...... 98 8.3.1 EMV Tokens ...... 99 8.3.2 Summary ...... 101 8.4 PAYMENT SYSTEMS SECURITY LAYERS ...... 101 8.4.1 Card-Present Transactions ...... 102 8.4.2 Card-Not-Present Transactions ...... 103 8.4.3 Best Practices ...... 104

9 E-PURSE AND STORED VALUE CARDS ...... 106 9.1 OPEN SYSTEM WITH E-CASH VALUE ON THE CARD AND CENTRAL ACCOUNT MANAGEMENT ...... 107 9.2 OPEN SYSTEM WITH NO CENTRAL ACCOUNT MANAGEMENT ...... 108 9.3 CLOSED SYSTEM WITH SEMI-OFFLINE ACCOUNT MANAGEMENT ...... 109 9.4 CLOSED SYSTEM WITH ONLINE CENTRAL ACCOUNT MANAGEMENT (PREPAID ONLINE) ...... 110 10 TRANSPORTATION AND PARKING PAYMENT ...... 112 10.1 TRANSIT ...... 112 10.1.1 Traditional Transit Fare Payment Systems ...... 113 10.1.2 Smart Card Use in Public Transit ...... 114 10.1.3 Transit and Open Contactless Bank Card Payment ...... 123 10.1.4 Transit Standards, Specifications and Guidelines ...... 127 10.1.5 Developments in Transit Payment ...... 129 10.2 PARKING ...... 131 10.2.1 Parking Market Segments ...... 132 10.2.2 Use of Smart Card Technology in Parking ...... 135 10.2.3 Smart Card Benefits for Parking ...... 136 11 SAMPLE SMART CARD PAYMENT MODELS ...... 141 11.1 TRANSIT ...... 141 11.1.1 Washington Metropolitan Area Transit Authority and Surrounding Area ...... 141 11.1.2 Utah Transit Authority ...... 142 11.1.3 Hong Kong Octopus Card ...... 144 11.2 PARKING ...... 145 11.2.1 Washington Metropolitan Area Transit Authority ...... 145 11.2.2 Parking Operations in Israel ...... 149 12 RELEVANT STANDARDS AND SPECIFICATIONS ...... 151 12.1 STANDARDS RELEVANT TO SMART CARD PHYSICAL CHARACTERISTICS ...... 151 12.2 STANDARDS RELEVANT TO TECHNOLOGIES WHICH COULD BE FOUND ON A SMART CARD ...... 151 12.3 STANDARDS AND SPECIFICATIONS RELEVANT TO TECHNOLOGIES RELATED TO THE CARD INTERFACE ...... 152 12.4 STANDARDS AND SPECIFICATIONS RELEVANT TO THE CARD COMMANDS AND APPLICATION DATA STRUCTURES ...... 152 12.5 STANDARDS AND SPECIFICATIONS RELEVANT TO ISSUERS OR SPECIFIC INDUSTRY SECTORS ...... 152 13 REFERENCES ...... 153 14 ACKNOWLEDGEMENTS ...... 157

1 Introduction This module is part of the Smart Card Alliance CSCIP/Payments certification. The module focuses on how smart cards are used in payment and payment-related applications, and includes more in-depth material than the payments module in the general CSCIP certification. After reviewing this module, CSCIP/P applicants should be able to answer the following questions and be familiar with examples of reference smart card implementations.  What are the drivers and benefits for smart card technology in payment applications?  How are smart cards used for bank card payments?  What is EMV and how do EMV-based financial transactions work?  What is the status of the U.S. migration to EMV chip cards and acceptance?  What are the different card authentication and cardholder verification methods used in EMV?  What changes are needed in the issuing, acquiring and merchant POS infrastructure to support EMV?  How are encryption and tokenization used to secure the payments infrastructure? How do EMV, encryption and tokenization work together?  What are contactless payment transactions and how do they differ from magnetic stripe- based transaction?  What are mobile payments? How do NFC mobile contactless payments differ from other mobile payments approaches? How are NFC mobile contactless payments implemented?  How can remote transactions for online banking and e-commerce be secured?  How are smart cards used for e-purse or stored value payment?  How are smart cards used for transit and parking payment applications? What are emerging trends and standards in transit payment?  What are the relevant standards for smart cards used for payment applications?

2 Smart Card Market Drivers and Benefits for Payments and Financial Transactions Both contact and contactless smart cards are used for many payment and payment-related applications worldwide. Smart card-based payment applications may be categorized across two dimensions:  The configuration of the payment platform used to deliver payment functionality as either an: - Open loop payment system - Closed loop payment system  The location of where the value that is available to the cardholder is stored, either: - Held as value in the memory of the card - Held in an account in a back office The matrix in Figure 1 provides an overview of the relationships between these two dimensions and provides examples for each category. The examples identified in the matrix are discussed in further detail throughout this module. Each smart card-based payment application or product can be mapped into one of the four categories defined in Figure 1. Figure 1. Payment Application Dimensions and Examples

Payment Closed Loop Payment System Open Loop Payment System Applications

 Traditional transit fare  Visa Cash payment cards (e.g., Hong Card-Based  Mondex Stored Value Kong Octopus)  SmartMeter parking card

 Merchant stored value cards  Bank-issued EMV credit and (e.g., Starbucks card) debit chip cards  Gift cards  Contactless bank cards (e.g., Back Office Discover D-PAS; ExpressPay  New transit fare collection by American Express; Account- systems (e.g., Chicago Transit Based MasterCard PayPass; Visa Authority, SEPTA, payWave) Washington, DC SmarTrip)  Electronic toll collection (e.g., EZ-Pass, FasTrak)

This section describes the drivers for smart card technology being used for payment applications and the benefits that the technology offers for payment and payment-related transactions. Additional information on benefits for specific markets and applications are included in the sections that follow.

2.1 Reducing Fraud and Enhancing Security A primary driver for smart card technology in payment applications is its ability to enhance the security of the payment card and the payment transaction to address fraud. Historically, magnetic stripe technology was used for payment applications. Magnetic stripe technology is limited with respect to modern security techniques as payment transactions rely on static account numbers or data stored on the card. Because this static data is easily copied, information can be stolen and duplicate magnetic stripe cards created. Within the payment systems, fraud checks are therefore performed in the back-end systems to manage the risk of counterfeit or stolen cards being used. Smart cards address the growing problem of fraud and offer a secure solution for both open and closed payment systems. Smart card technology provides strong payment card security. Well-designed smart cards are very difficult to duplicate or forge and data stored in the chip cannot be modified without proper authorization (a password, biometric authentication or cryptographic access key). Smart cards help to deter counterfeiting and thwart tampering. Smart cards include a variety of hardware and software capabilities that detect and react to tampering attempts and help counter possible attacks. Sensitive payment account information and/or value can be securely stored on the smart card. For example, the cardholder personal identification number (PIN) can be stored on the card and verified by the card without having to go online to the card issuer's host system. The secure element used in mobile phones to securely store and enable NFC mobile payments transactions is a smart card chip. The smart card and the payment terminal can interact to make decisions about whether a transaction can take place. The smart card can generate dynamic data with each transaction, providing both better information for authorization decisions and rendering transaction data impervious to fraudulent use.

2.2 Enhancing Consumer Convenience and Confidence Smart payment devices enhance consumer confidence by improving the security of the payments system, decreasing the incidents of fraud and improving ubiquitous card acceptance. Consumer convenience and security are enhanced by supporting a variety of cardholder verification methods. Contactless payment enhances consumer convenience at the POS. Another advantage for consumers is that they control the contactless payment device. The device is always in the consumer’s possession, reducing the possibility of leaving it somewhere accidentally and minimizing the potential for fraud. Smart stored value payment cards provide consumers with a secure alternative payment mechanism, and smart contactless transit payment cards allow consumers to quickly and reliably pay fares.

2.3 Enhancing the Business Case with Multiple Applications Smart card technology enables an issuer to include and offer multiple applications on one card. By taking advantage of the smart card chip’s capabilities, issuers can enhance the business case for implementing smart payment cards and increase the ability of that system to handle future needs. Examples of applications that could be offered on a smart payment card include:  Credit/debit bank card payment  Choice of credit, debit or prepaid on one card  Proprietary payment (e.g., transit payment application or campus payment application)

 Loyalty  Electronic purse  Electronic benefits  Identity applications for physical and/or logical access 2.4 Improving Efficiency and Increasing Sales Volume at the Merchant POS Contactless and mobile NFC payments improve efficiency at the merchant POS. Contactless and mobile NFC payments can be faster and more convenient for consumers than contact chip, cash or magnetic stripe card payments. Increased speed and convenience generate greater sales volumes and increase customer spending. Customers not only spend more: the use of contactless payments also reduces the requirement for and cost of handling cash while also improving operational efficiencies and reducing terminal maintenance costs.

2.5 Supporting Innovation and Differentiation Both contact and contactless smart card technology can offer issuers and merchants opportunities for innovation and differentiation. Issuers can differentiate their contactless payment products with form factors, tailored to specific consumer preferences (for example, key fobs, mobile devices, micro tags, or stickers), and provide products and services that take advantage of the functionality available with the new form factors. Both contact and contactless payment devices can support multiple applications. Merchants and issuers can collaborate on payment products that blend specific features, packaging (cards, tokens, mobile phones), and applications and target different customer segments that have very particular requirements for the shopping experience.

3 Bank Card Payments Bank cards are defined as any card issued by a bank that can access a consumer's financial resources. Bank cards include the following:  Credit cards, which provide access to a consumer's credit line. Credit cards are typically used at merchant locations with either a consumer signature or without a signature required (i.e., no cardholder verification method (CVM).  Debit cards, which directly access a consumer's checking or savings account. Debit cards can be used at merchant POS locations either with or without a consumer-unique personal identification number (PIN).  ATM cards, which provide consumers with access to their checking and savings accounts through automated teller machines (ATMs) using a PIN to authenticate that they are the owner of the account. ATM cards can be used at merchant POS locations, but require a PIN for cardholder authentication. Typically, ATM cards are also debit cards.  Prepaid cards, which provide access to a prepaid value, rather than a line of credit. The card is used until the value is depleted and the card is discarded or reloaded. Bank cards, bank card message formats, and bank card processing requirements are defined by ISO/IEC standards and by specifications developed by the payments industry and payment brands. Key standards and specifications for bank cards include:  ISO/IEC 7810, defining the physical card characteristics.  ISO/IEC 7811, defining the specifications for embossing cards and encoding data onto a card's magnetic stripe.  ISO/IEC 7812, specifying the numbering system for the identification of issuers of cards.  ISO/IEC 7813, specifying the data structure and data content of magnetic tracks 1 and 2, which are used to initiate financial transactions.  ISO/IEC 7816, specifying physical dimensions, electrical interface, communications protocols, card logical structure (files and data elements), various commands used by the application programming interface for basic use, application management, biometric verification, cryptographic services and application naming for smart cards.  ISO/IEC 8583, specifying interchange messages for financial transaction card originated messages.  ISO/IEC 14443, specifying the interfaces for a contactless smart card.  EMV 4.3, specifying the standard smart card and transaction terminal operations to support globally interoperable financial smart cards.  Specifications from American Express, China UnionPay, Discover, JCB, MasterCard, and Visa, that define the payment application and the security requirements for branded bank cards. Bank cards currently use two technologies to store account information and to allow merchant POS terminals to read the information electronically – magnetic stripe technology and smart card technology.

3.1 Bank Card Technology and Processing: Magnetic Stripe Cards Up until the late 1990s, magnetic stripe technology was used worldwide for bank cards. Figure 2 shows the information stored on tracks 1, 2 and 3 of the magnetic stripe for bank cards.1 Track 3 is not used in most applications. Figure 2. Magnetic Stripe Information on Bank Cards

Figure 3 illustrates the flow of a traditional magnetic stripe credit card payment transaction.

Figure 3. Credit Card Payment Transaction Flow2

Authorization Request Authorization Request Authorization Request

Authorization Authorization Authorization Response Response Response MerchantMerchant PaymentPayment MerchantMerchant Acquirer/Acquirer/ CardCard IssuerIssuer BrandsBrands Transaction ProcessorProcessor Transaction Transaction

Settlement Settlement Message Settlement Message Message

MerchantMerchant BankBank

The magnetic stripe payment transaction includes the following steps:

1 EMV 101, Guy Berg, Datacard Group, presentation, “EMV Roadmap Implementation Options,” Smart Card Alliance workshop, May 2, 2011 2 Source: Booz Allen Hamilton. This figure shows the transaction flow in an 'open loop' payment network (such as MasterCard and Visa); it does not show transaction flow for a 'closed loop' payment network where the acquirer, network and issuer functions are performed by a single entity, such as American Express.

1. The merchant’s point-of-sale (POS) system sends an authorization request for the transaction (including the cardholder account number, transaction amount, card security code3 for physical merchants) to the merchant acquirer/processor, who then sends it through the payment brands' financial networks to the card issuer. The merchant POS system can request additional information from the card or the cardholder (for example, zip code (for address verification (AVS)), signature, PIN) to authenticate the cardholder and/or to establish that the card was present for the transaction. 2. The issuer performs the necessary security checks (e.g., checking the security information included with the transaction, determining the validity of the payment card, checking whether the account is in good standing and has sufficient “open to buy” funds available, analyzing cardholder behavior to assess if the transaction could be fraudulent), authorizes or denies the transaction, and returns an authorization response to the merchant acquirer/processor, who passes it to the merchant. 3. Authorized transactions are captured (cleared) from the merchant every day, and a settlement message is sent over the financial networks to transfer funds to the merchant account (transaction amount less merchant discount rate)4. It is important to note that magnetic stripe card transactions rely on static account numbers and the card security code. Because this data is static, the information can be easily stolen and reused to create a duplicate magnetic stripe card. This practice is known as skimming. Within the financial system, fraud checks are performed in the back-end systems to manage the risk of counterfeit or stolen cards being used; however, the card issuer’s back-end system cannot recognize cloned cards from the data passed for authorization.

3.2 Bank Card Technology and Processing: Smart Cards Smart card technology introduced three significant factors to a payment card beyond the features provided by magnetic stripe card technology.  The first is greater storage capacity for information. In comparison to the magnetic stripe, which holds 210 bits in track 1 and 75 bits in track 2, the integrated circuit chip (ICC) on smart cards in the early 1990s provided 2k bytes of storage space. ICC storage capacity on smart cards used in the payment industry today ranges from 4k bytes to 64k bytes, and ICCs with even greater storage capacity are available. An increasing number of ICCs now use flash memory and offer 120k bytes to 240k bytes for payment.  The second factor is the ability to reliably write information back to the payment card’s ICC at the time of the transaction (e.g., to update counters or implement other issuer updates).  The third factor is the security provided by the microprocessor embedded in the ICC, along with the ability to load applications, not just data onto the ICC. The combination of these factors opened up a wide range of possible approaches toward implementing smart card-based payment applications. Initially smart card-based payments had no standards like the magnetic stripe data standards, and, as a result, many smart cards were introduced with different operating systems and proprietary payment applications. Issuers and smart card vendors introduced new ways to

3 The card security code is a 3 or 5 digit numeric code either written on the payment card magnetic stripe or printed on the card that are used by the financial payment brands for credit, debit, and prepaid transactions to protect against card fraud for swipe or online transactions The terminology for the card security code varies by brand: CSC – Card Security Code for American Express; CID – Card Identification Data for Discover; CVC or CVC2 – Card Validation Code for MasterCard; CVV or CVV2 – Card Verification Value by Visa. 4 See additional discussion in Section 3.3.

leverage the computing power, the data storage capacity and the security capabilities of smart cards. The problem with this approach was that every terminal also required a proprietary application in order to interact with the payment application on the smart card.

3.2.1 EMV Europay, MasterCard and Visa (EMV) recognized this problem and joined together to build a set of standards that provided a path to leverage smart card capabilities in the payment industry. Since that time, American Express, China UnionPay, Discover and JCB have all joined in support of the EMV specifications. As result of the EMV specifications, the EMV chip application is now implemented with many different chip operating systems, and terminals are able to communicate to them using the exact same commands. The EMV specification,5 first available in 1996, defines technical requirements for bank cards with embedded microchips (i.e., smart cards) and for the accompanying point-of-sale (POS) infrastructure. EMV was designed to improve consumer bank card payment security by providing enabling features for reducing fraudulent payments resulting from counterfeit and lost and stolen cards.6 According to EMVCo, EMV defines the following features to address fraud:  Card authentication features, to verify that the card is genuine.  Risk management parameters, to define the issuer conditions for permitting the card to be used and for defining when transactions are performed online vs. offline. For example, issuers may set a maximum offline transaction amount or maximum cumulative number of offline transactions. In addition, these limits and counters can be configured to only be applicable if the terminal is not able to go online.  Transaction integrity features, enabling digital signatures on the payment data.  Cardholder verification features, to protect against lost and stolen cards, including the EMV-unique cardholder verification method, offline PIN. EMV has had a significant impact on reducing fraud. The UK Cards Association reported a dramatic reduction in fraud since the introduction of EMV cards. "Fraud on lost and stolen cards is now at its lowest level for two decades and counterfeit card fraud losses have also fallen and are at their lowest level since 1999. Losses at U.K. retailers have fallen by 67 per cent since 2004; lost and stolen card fraud fell by 58 per cent between 2004 and 2009; and mail non-receipt fraud has fallen by 91 per cent since 2004."7 Canada had similar experience with their migration to EMV. Counterfeit credit card fraud declined from almost C$200 million in 20088 to approximate C$53 million in 2013.9 Interac reported debit card fraud losses dropped from C$142.3 million in 2009 to less than C$16.2 million in 2014 (for fraud inside Canada).10 The experiences of the U.K. and other countries that have adopted chip have shown a reduction of domestic card-present fraud. But their experiences have also shown a migration to other types

5 The original founders of the EMV standards body were Europay, MasterCard, and Visa—hence the acronym “EMV.” Information on the specifications is available at http://www.emvco.com. 6 A Guide to EMV, Version 1.0, EMVCo white paper, May 2011 7 New Card and Banking Fraud Figures, The UK Cards Association, March 10, 2010, http://www.theukcardsassociation.org.uk/media_centre/press_releases_new/-/page/922/ 8 “EMV Migration Canada,” Tracey Black, GFH Group, 2013 Smart Card Alliance Payments Summit, February 2013. 9 Canadian Bankers Association. 10 “Interac® debit card fraud losses fall to record low,” Interac press release, Feb. 25, 2015, http://www.interac.ca/en/press-releases/interac-debit-card-fraud-losses-fall-to-record-low

of fraud, namely card-not-present (CNP) fraud and cross-border counterfeit fraud (particularly ATM fraud). Fraud migration offsets some of the savings from the decrease in domestic card- present fraud. This reality reinforces the need for a layered approach to security, even with EMV deployment, to address fraud migration and other security vulnerabilities.

3.2.1.1 EMV Chip Migration Financial institutions worldwide are issuing or are migrating to issue EMV bank cards to businesses and consumers. Table 1 shows EMVCo’s report of worldwide EMV deployment and adoption as of fourth quarter 2014.11 EMVCo reported that 3.4 billion EMV cards have been issued globally, an increase of 43% from the fourth quarter 2013. Table 1. EMVCo Report on EMV Deployment and Adoption12

2013 2014 Adoption Adoption Region EMV Chip Cards EMV Chip Cards Rate Rate Canada, Latin America and 471M 54.2% 544M 59.5% the Caribbean Asia Pacific 942M 17.4% 1,676M 25.4% Africa and the 77M 38.9% 116M 50.5% Middle East Europe Zone 794M 81.6% 833M 83.5% 1 Europe Zone 84M 24.4% 153M 40.4% 2 United States - - 101M 7.3%

The EMV Migration Forum’s estimate for U.S. EMV chip card issuance and installed EMV chip- capable POS terminals is shown in Table 2. As of the end of 2014, approximately 120 million cards have been and 4.5M EMV-capable13 terminals were installed, accounting for approximately 10% of cards in the market and 37% of the POS terminals. Information on U.S. EMV chip card issuers can be found on the EMV Connection web site.14 Table 2. U.S. EMV Deployment and Adoption15 EMV Chip- EMV Chip Region Adoption Rate Capable Adoption Rate Cards Terminals United States 120M 10% 4.5M 37%

11 “EMVCo Reports 3.4 Billion EMV Chip Payment Cards in Global Circulation,” EMVCo press release, May 6, 2015, http://www.emvco.com/media_center.aspx?id=48 12 EMVCo: “Figures reported in Q4 2013 and Q4 2014 represent the latest statistics from American Express, Discover, JCB, MasterCard, UnionPay and Visa, as reported by their member institutions globally.” 13 EMV-capable POS terminals are terminals that has a chip card reader and can accept and EMV payment application. While the terminal is capable, the EMV functionality may or may not be enabled. 14 http://www.emv-connection.com/u-s-emv-issuers/ 15 “Merchant Considerations for U.S. Chip Migration,” EMV Migration Forum webinar, September 2014, http://www.emv-connection.com/merchant-considerations-for-u-s-chip-migration/.

EMVCo has also reported on the percentage of card-present transactions that are EMV – i.e., an EMV chip card is used at an EMV-enabled chip terminal. As of fourth quarter of 2014, “32% of all chip card-present transactions – both contact and contactless – conducted globally between January and December 2014 used EMV chip technology.”16 Table 3 shows the percent of card- present transactions that are EMV by region.17 Table 3. EMV Card-Present Transactions18 Percent of Card-Present Region Transactions that Are EMV Canada, Latin American and 85.41% the Caribbean Asia Pacific 27.01% Africa and the Middle East 80.00% Europe Zone 1 96.60% Europe Zone 2 58.04% United States 0.12%

3.2.1.2 U.S. Fraud Liability Shift Dates19

Globally, EMV migration has been driven by the need to reduce fraud losses, by payment brand requirements and incentives, and by fraud liability shift -- where liability for fraudulent transactions is born by the party with the least secure technology. In 2011 and 2012, all of the global payment brands announced their plans for U.S. migration to EMV, with acquirers required to handle full EMV chip data in transactions in April 2013. There are slight variations in fraud liability shift dates for the payment brands, but two most important ones align for all of the brands – the Oct. 2015 fraud liability shift for merchants for in- store transactions and the Oct 2017 date for automated fuel dispensers.  October 2015. Beginning in October of 2015, global payment brands and certain U.S. debit networks plan to implement fraud liability shifts that will impact card-present counterfeit chip card transactions and/or lost or stolen chip card transactions. As of that date, liability for those transactions generally will shift to the acquirer/merchant in certain cases if they do not use EMV chip-enabled devices and applications to process payment transactions. The impact of these October 2015 liability shifts to the acquirer/merchant depends on whether: - EMV chip cards (domestic and international - including credit and debit cards) are used; and - EMV chip-enabled point-of-sale (POS) card payment acceptance devices/applications are deployed (excluding automated teller machines (ATMs) and automated fuel dispensers (AFDs)), including in-person POS retail devices, unattended terminals, kiosks and vending machines, and mobile payment acceptance devices (MPOS).

16 EMVCo, ibid. 17 EMVCo, ibid. 18 Ibid. 19 “Understanding the 2015 U.S. Fraud Liability Shifts,” EMV Migration Forum white paper, May 2015, http://www.emv-connection.com/understanding-the-2015-u-s-fraud-liability-shifts/

 October 2017. Beginning in October 2017, the fraud liability shift will also apply to automated fuel dispensers (AFD). American Express, Discover, MasterCard, UnionPay and Visa all have a counterfeit fraud liability shift starting in October 2015. With this liability shift, when a merchant accepts a magnetic stripe card that was counterfeited with track data copied from an EMV chip card, and the card is subsequently swiped at a POS device/application that is not EMV chip-enabled, and the transaction is successfully processed, the acquirer/merchant may be liable for the chargeback resulting from the fraud. Liability remains with the issuer for all other counterfeit card transaction scenarios. Figure 4 illustrates examples of the impact of the fraud liability shift for different transaction scenarios. American Express, Discover and MasterCard also have a lost and stolen fraud liability shift for attended transactions starting in October 2015. With this liability shift, if a lost or stolen chip and PIN card is used at a less secure terminal, fraud liability will shift to the acquirer/merchant. Figure 5 illustrates examples of the impact of the fraud liability shift for different transaction scenarios. UnionPay and Visa do not have a liability shift for lost or stolen card fraud, and accordingly, this liability remains with the issuer.

*October 2017 for AFD. **With or without PIN capabilities Figure 4. Counterfeit Fraud Liability Examples20

20 “Merchant Considerations for U.S. Chip Migration,” EMV Migration Forum webinar, September 2014. Graphic courtesy of Heartland Payment Systems, http://www.emv-connection.com/merchant- considerations-for-u-s-chip-migration/.

Figure 5. Lost/Stolen Card Liability Fraud Examples: American Express, Discover and MasterCard21

The following are other U.S. EMV migration milestones announced by the global payment brands.  Effective October 2012, Visa and MasterCard expanded their programs to eliminate the requirement for eligible merchants to annually validate their compliance with the Payment Card Industry (PCI) Data Security Standard (DSS) for any year in which at least 75 percent of the merchant’s transactions originate from chip-enabled terminals. To qualify, terminals must be enabled to support both contact and contactless chip acceptance, including mobile contactless payments based on NFC technology. These terminals must also continue to support standard magnetic stripe transactions.  Effective October 2013, merchants were eligible to receive relief from PCI DSS reporting requirements if the merchants’ POS acceptance locations, where 75% of their transactions occur, are enabled to process American Express EMV chip-based contact and contactless transactions.  Effective October 2013, MasterCard provides account data compromise (ADC) relief for merchants. On this date, if at least 75% of MasterCard transactions originate from EMV- compliant contact and contactless POS terminals, the merchant is relieved of 50% of account data compromise penalties. In October 2015, if at least 95% of MasterCard transactions originate from EMV-compliant POS terminals, the merchant is relieved of 100% of account data compromise penalties.  Effective October 2016, the MasterCard fraud liability shift goes into effect for ATMs.  Effective October 2017, the Discover and Visa fraud liability shift goes into effect for ATMs. Additional information on the payment brand requirements for EMV chip card issuance and POS acceptance can be found on the EMV Connection web site, http://www.emv-connection.com.

21 Ibid.

Additional information about EMV can be found in Section 4.

3.2.2 Contactless Payments In addition to the migration to EMV, bank cards are also migrating to contactless smart card technology – either contactless cards based on the ISO/IEC 14443 standard or NFC-enabled mobile devices that are compatible with ISO/IEC 14443. Contactless bank card payment applications deliver increased payments security and added convenience and functionality for consumers and merchants. Contactless payments may be implemented as contactless EMV or, historically in the U.S., as contactless magnetic stripe data (MSD). Contactless MSD was implemented to leverage the online magnetic stripe infrastructure to speed contactless payments deployments. Contactless payment card and device issuance worldwide is moving to contactless EMV. Additional information about contactless payment technology and applications can be found in Section 5.

4 EMV EMV is an open-standard set of specifications for smart card payments and acceptance devices. EMVCo, owned by American Express, China UnionPay, Discover, JCB, MasterCard, and Visa, manages, maintains and enhances the EMV specifications and associated approval procedures, to ensure global interoperability of chip-based payment cards with acceptance devices including point of sale terminals and ATMs.22 Over the years, EMVCo has maintained and revised the specification to sustain the highest level of security. EMVCo also develops and manages new functionality required by the market. EMV’s primary purpose is to ensure that standards for smart card-based payments are interoperable globally. The standards were initially focused on contact cards; however, certain contactless card standards are now included. The EMV specification initially started out as a terminal specification and has evolved to contain four books: 1) Book 1: The ICC to Terminal Interface specification. 2) Book 2: Security and Key Management 3) Book 3: Application Specifications 4) Book 4: Other Interfaces As with any specification, the EMV specifications have evolved over time and continue to evolve. The first release was EMV ‘96 version 2.0 in 1996 and the second release was version EMV ’96 3.1.1 in 1998. In December of 2000, EVM 4.0 was released which is also known as EMV 2000. The current version of EMV is release 4.3, published in November 2011. EMVCo also publishes specifications defining new functionality, including:  “EMV Common Payment Application (CPA) Specification,” published in 2008, which is a functional description of an issuer payment application that complies with the EMV common core definition.  “EMV Contactless Specifications for Payment Systems,” first published in 2009, which define the architecture, general requirements, entry point, kernel and contactless communication protocol to support contactless payments for any smart card form factor (e.g., card, sticker, mobile phone). The current version of the specifications is release 2.1, published in March 2011. When the EMV specifications were written, they added support for a significant new capability, a means to authenticate cards offline – without the need for an authorization approval from the card issuer, payment network or acquirer processor – and thereby significantly reduced offline transaction risk. Support for offline authentication and authorization was a significant development because many countries around the world had unreliable telecommunications, and therefore could not perform online authorizations. For this reason, people frequently suggest that EMV is meant for offline transactions environments. However, EMV was designed to provide new security benefits to both online and offline transaction environments. As part of its charter to define a set of requirements to ensure worldwide interoperability and acceptance of secure payment transactions, EMVCo manages the EMV specifications and related testing processes. EMV specifications are available based on contact chip, contactless chip, common payment application (CPA), card personalization, and tokenization. There are also EMV documents and materials regarding mobile payments. EMV specifications can be found at http://www.emvco.com.

22 http://www.emvco.com/about_emvco.aspx

4.1 EMV Security At the heart of EMV is the underlying security framework that provides fraud protection for both offline and online transactions. The security uses a combination of symmetric and asymmetric key technology. In addition to storing payment information in a secure chip rather than on a magnetic stripe, using EMV improves the security of a payment transaction by adding functionality in three areas:23 1. Card authentication – protecting against counterfeit cards 2. Cardholder verification – authenticating the cardholder and protecting against lost and stolen cards 3. Transaction authorization – using issuer-defined rules for authorizing transactions

4.1.1 Card Authentication Methods (CAM) Card authentication is a security mechanism that protects the payment system against counterfeit cards. These security mechanisms are defined in the EMV specifications and the associated payment brand chip specifications. Card authentication can be online, offline or both.

4.1.1.1 Online Card Authentication Online card authentication requires the transaction to be sent online for the issuer to authenticate and authorize in the same way magnetic stripe transactions are sent online today in the U.S. The important difference is the chip card’s use of symmetric key technology to generate a cryptogram using a shared secret key. This cryptogram, called the Authorization Request Cryptogram (ARQC), is validated by the issuer during the online authorization request. The ARQC is the dynamic data that makes an EMV transaction unique and provides card-present counterfeit fraud protection. The chip generates this cryptogram by applying an algorithm to the card, device, and transaction data, and then signing all of the data with a Triple DES (3DES)24 key (referred to as the Unique Derivation Key (UDK)), that is stored in a secure area on the chip. Because some of the data used in the cryptogram generation is different for each transaction, the resulting cryptogram is unique for each transaction.

4.1.1.2 Offline Card Authentication Offline card authentication is an optional feature in EMV that facilitates the ability to authenticate the legitimacy of the chip in an offline mode. The chip validation is performed between the EMV chip card and EMV terminal. Three methods of offline card authentication are defined by EMVCo, offering increasing levels of protection against counterfeit cards. Offline card authentication approaches are:  Static data authentication (SDA)  Dynamic data authentication (DDA),  Combined dynamic data authentication/application cryptogram generation (CDA)

4.1.1.2.1 Static Data Authentication (SDA) As of 2009, most cards issued worldwide support SDA. SDA calculates a cryptogram using a static public key certificate and static data elements. SDA relies on a public key infrastructure

23 In addition to payment application security features, an EMV card includes a secure smart card IC, which is tamper-resistant and includes a variety of hardware and software capabilities that immediately detect and react to tampering attempts, countering possible attacks. 24 Triple Data Encryption Standard (TDES).

(PKI) in which the payment brands act as the certificate authorities (CAs) and provide public key certificates to participating issuers. During personalization, the issuer uses the issuer’s private key to sign a set of card-specific data and loads the signed data onto the card along with the issuer’s public key certificate. To authenticate a card, a terminal loads the payment brand’s root public key. The terminal uses the payment brand’s root public key to validate the issuer’s public key certificate. The terminal then extracts the issuer’s public key from the validated certificate. The terminal uses the extracted public key to validate the static card data (which has been signed by the issuer’s private key). This process is known as static data authentication because the data used for authentication is static—the same data is used at the start of every transaction. If this data can be skimmed, it can be used to recreate a transaction. SDA is the simplest method of chip card authentication and provides the lowest level of protection against counterfeit fraud. Although the current level of chip card counterfeit fraud is low, it can increase as chip card markets become more mature and other opportunities for fraud are removed.

4.1.1.2.2 Dynamic Data Authentication (DDA) DDA is similar to SDA but goes one step further. DDA calculates a cryptogram for each transaction that is unique to the specific card and transaction. In addition to the issuer key pair, an asymmetric (RSA) key pair is generated for each card. The issuer then creates an associated public key certificate by signing the card public key. All data is loaded onto the card during personalization. To authenticate a card, terminals follow basically the same process as for SDA, except that a random number is also sent to the card to be signed by the card private key. The terminal then validates the signature using the card public key. DDA protects against card skimming and counterfeiting. The technique is similar to the dynamic card verification value (dCVV) and dynamic card verification code (dCVC) which are used in online contactless magnetic stripe data (MSD) transactions.

4.1.1.2.3 Combined DDA with Application Cryptogram (CDA) CDA combines DDA functionality with an additional application cryptogram at the end of the transaction. This final application cryptogram is used to assure that the data in the transaction maintain integrity even after the transaction is completed. In other words, the use of a final application cryptogram prevents the type of fraud in which data are manipulated by a wedge device placed between the card and the terminal.

4.1.2 Cardholder Verification Methods (CVM) Cardholder verification authenticates the cardholder. EMV supports four CVMs:  Offline PIN  Online PIN  Signature  No CVM Depending on payment brand rules and issuer preference, chip cards are personalized with a list of CVMs in priority order of desired use. This is done to maximize acceptance across a wide a variety of terminals types and locations as possible. Different terminal types support different CVMs. For example, attended POS devices, in addition to supporting signature, may support

online or offline PINs (or both), while some unattended card-activated terminals may support "no CVM." The terminal will use the highest priority CVM listed on the chip that the terminal supports.

4.1.2.1 Offline and Online PIN Offline PIN is the only method of cardholder verification supported by EMV that is not available with magnetic stripe cards. The offline PIN is stored securely on the card. When the cardholder enters a PIN during a transaction, the POS terminal sends the PIN to the EMV card for verification. The card compares the entered PIN to the stored PIN and sends the result of the comparison back to the POS terminal, which can then either approve the transaction offline or send the transaction and PIN verification result to an issuer host for authorization. The offline PIN is never sent to the issuer host—only the result of the comparison is passed. Offline PIN can be supported in two ways, with either a plain text offline PIN or an enciphered offline PIN.  Plain text offline PIN. The chip reader sends the PIN to the chip on the card as plain text.  Enciphered offline PIN. Either the secure component in the POS device (for example, the chip reader) or the PIN pad itself enciphers the PIN, using an authenticated encryption public key from the chip. The enciphered PIN is sent to the chip, where the PIN is deciphered using the private key from the chip. Online PIN is not stored on the card because the PIN is sent online for the issuer to validate. Online PIN is currently supported on magnetic stripe cards and widely available at POS terminals and ATMs today. The cardholder enters the PIN at the POS terminal, and the PIN is encrypted by the PIN pad and sent online to the host for validation. The security of the online PIN is based on Triple Data Encryption Standard (TDES) and standardized across the globe. For an ATM, online PIN is required and is the only valid CVM. As a result, any implementation of offline PIN will still require online PIN if ATM access is needed. If a card supports both online and offline PIN CVMs, the issuer must ensure that the two PINs are synchronized. Synchronization is important, because when cardholders are asked to enter a PIN, they do not know whether they should enter their offline PIN or online PIN. In general, online PIN or offline PIN CVMs directly protect against fraud resulting from lost, stolen, and never-received cards.

4.1.2.2 Signature Signature verification requires a written signature at the POS, as is currently required with magnetic stripe cards. Validation occurs when the signature on the receipt is compared to and matches the signature on the back of the card.

4.1.2.3 No CVM EMV also supports transactions that require "no CVM." No CVM is typically used for low value transactions or for transactions at unattended POS locations.

4.1.3 Transaction Authorization EMV transactions can be authorized online or offline. For an online authorization, transactions proceed as they do with magnetic stripe cards. The transaction information is sent to the issuer, along with a transaction-specific cryptogram, and the issuer either authorizes or declines the transaction. In an offline EMV transaction, the card and terminal communicate and use issuer-defined risk parameters that are set in the card to determine whether the transaction can be authorized. Offline transactions are used when terminals do not have online connectivity (e.g., at a ticket kiosk) or in countries where telecommunications costs are high.

Cards can be configured to allow both online and offline authorization, depending on the circumstances. It is also important to note that use of the offline PIN CVM is not restricted exclusively to offline authorized transactions. Offline PIN can be used as the CVM, and the transaction can then go online for authorization in the majority of circumstances. It is important to differentiate between offline authentication and offline transaction authorization. EMV is designed so that both offline and online authentication can be leveraged in a single transaction. Even when transactions are authenticated online, offline authentication procedures can be performed as part of the EMV transaction if supported by the card. Performing offline authentication neither requires nor implies that the transaction be performed completely offline. Offline capability is designed into EMV to address environments where reliable online communication is not available or is expensive. With EMV, a card can be required to perform transactions offline even when terminals are online-capable until a certain dollar amount or number of consecutive transactions is reached, at which time the transaction goes online. The same offline parameters are used for terminals that are completely offline.

4.1.4 EMV Use of Symmetric and Asymmetric Cryptography EMV uses both symmetric and asymmetric cryptography to protect cards and transactions. First, EMV leverages the security found in integrated circuit cards (ICCs) and requires symmetric authentication keys to be submitted to gain access to the ICC memory. This helps protect cards in transit to issuers and in warehouse inventory. Protecting card stock is an important deterrent against the creation of authentic-looking counterfeit cards. Second is the EMV application logical security. For this, EMV specifies special purpose symmetric access keys for personalization, for post-issuance updates, and for card and transaction authentication purposes. These keys help: 1) Prevent unauthorized personalization of cards, 2) Secure transmission of card updates once they are in the cardholders' hands by encrypting all data that is to be sent to a card, 3) Authenticate a card and authorization request in an online transaction by validating an Authorization ReQuest Cryptogram (ARQC), and 4) Authenticate the issuer by the card validating the Authorization ResPonse Cryptogram (ARPC). For the symmetric key security to work, the issuer host system and the card must share each of the secret keys that are to be used. The keys are loaded onto the card during the personalization process and also placed in the hardware security module (HSM) used by the issuer's host authorization system. Data can then be encrypted or signed to create a cryptogram and decrypted, or a cryptogram validated, on the other side. For low-cost, always online transaction environments, online validation of the ARQC alone provides sufficient transaction security. Finally asymmetric keys and certificates, also known as public key infrastructure (PKI), are incorporated to facilitate card authentication in offline transaction environments. At a high level, the following describes how the EMV PKI certificates work. Before an issuer can begin issuing EMV cards, they must obtain an issuer’s public key certificate from the payment brand's certificate authority (CA). This issuer’s public key certificate then is loaded onto each card that is issued and, at the time of the transaction, the terminal authenticates the card’s certificate. The authentication is done by validating the issuer’s public key certificate using the corresponding CA public key that is loaded onto the terminals by the payment brands. The public key that is loaded to the terminals is the “partner” key of the private key that the payment brand used to sign the issuer’s public key certificate. This process enables card authentication without online connectivity.

Issuers are provided three certificate implementation options for card authentication – SDA, DDA and CDA – as described in Section 4.1.1.2. Each offers a different level of security based on how the certificate is generated. It is important to recognize that the offline security features described above, SDA, DDA and CDA, are not needed or required for online EMV transactions. However, these features can enhance the card validation process. DDA is a minimum requirement for cards that support offline data authentication in most regions of the world.

4.2 EMV Transaction Framework EMV changed the basic risk management workflow while leveraging all of the existing steps in the magnetic stripe card process presented in Section 3.1 of this document. With magnetic stripe cards, all risk management is performed during the transaction authorization process by a central system. The terminal simply serves the purpose of capturing the Track 1 or 2 data and passing it through to the central server. With EMV, components of the risk assessment are pushed out to the terminal and the card, facilitating greater risk management for offline transactions. In essence, the issuer loads a set of risk management parameters into the EMV application on the chip and the terminal responds by performing each of the functions indicated by those risk parameters. The risk parameters range from the cardholder verification method (i.e., requirement for a signature or PIN), to the form of cryptogram that is used by the card and terminal to perform an authentication routine. Other risk parameters address what the terminal should do under different authorization failure conditions or how a card can be used. Figure 6 is an overview of EMV transaction process using online card authentication. When the EMV card is inserted into the terminal, the terminal finds the EMV application and reads the EMV tags to get directions for handling the transaction. During this process, the chip is doing some risk assessment (1) and the terminal is doing some risk assessment (2) based on parameters set by the issuer in the EMV tags or the EMV profile (e.g., to determine if the card should be declined, if the transaction should go online or if it can be accepted as an offline transaction). At the end of that risk assessment, if the transaction is determined to go online, a dynamic cryptogram (the Authorization Request Cryptogram (ARQC)) is created, which is passed into a new set of EMV authentication data that gets sent through the acquirer to the issuer authorization system (3). The issuer authorization system validates the dynamic cryptogram (4) and may send an authentication cryptogram back in response (the Authorization Response Cryptogram (ARPC)). The APRC is passed back to the chip, so that the chip can authenticate the issuer – performing a mutual authentication. With a contactless EMV card or device, the ARPC is not typically returned since the chip may have left the proximity of the reader before a response can be returned. Figure 7 illustrates the EMV transaction process using combined online and offline authentication. In this process, the card is first authenticated using SDA, DDA or CDA. If the issuer requires a PIN as a cardholder verification method, the cardholder enters the PIN, and the PIN is validated by the card. The transaction then goes online for authorization, carrying the transaction data and the ARQC and proceeds as the online transaction shown in Figure 6.

Figure 6. EMV Transaction Framework using Online Card Authentication25

Figure 7. EMV Transaction Framework using Combined Online and Offline Card Authentication26

25 EMV in 10 Minutes, Guy Berg, Datacard Group, presentation, ‘EMV for Merchants and Merchant Acquirers: U.S. Migration Considerations,” Smart Card Alliance webinar, October 6, 2011, http://www.smartcardalliance.org/pages/activities-events-emv-for-merchants-and-acquirers-webinar 26 Ibid.

4.3 EMV Chip Software and Data Figure 8 illustrates the EMV chip software architecture and the evaluations and certifications that are used with each data layer. The first level is the chip operating system, which can be either open (such as GlobalPlatform Java Card or MULTOS) or proprietary. Card vendors have different chip operating systems that they offer for EMV cards. The operating system is selected by the card issuer and has no impact on the POS terminal or the acquiring system. The second level is the EMV application. EMV is a broad set of specifications which offers many options for implementation. Each of the payment brands has slightly different chip application implementations, for both contact and contactless transactions, and different EMV risk configuration options. The third level is the EMV data. Each issuer can choose which EMV options they want to implement (for example offline vs. online card authentication, type of CVM). This information is loaded onto the card when the chip is personalized. Figure 8. EMV Chip Software Components and Certifications

EMV Chip Architecture Evaluations and Certifications Operating System Level  EMVCo or MULTOS certify the  MULTOS open chip operating systems.  GlobalPlatform Java Card  Payment brands certify native  Native / Card Vendor Proprietary OS EMV implementations. EMV Application Level  American Express AEIPS (contact), ExpressPay (contactless)  Discover D-PAS  Payment brands certify the  JCB J Smart applications.  MasterCard Mchip (contact), PayPass Mchip / Magstripe (contactless)  Visa VSDC (contact), payWave qVSDC / MSD (contactless) Data Level  Personalization data  Payment brands validate the  Risk management parameters card personalization prior to  Cardholder data production issuance.  Security keys and certificates Source: Datacard Group, Smart Card Alliance EMV certification and evaluation schemes use an industry standardized and layered approach which is stepwise applied to ICC, then operating system, then application. Each piece of the value chain can reuse the prior step’s certification to achieve its own.  EMVCo evaluates all EMV-based smart card ICs and implementations of the EMVCo Common Payment Application to ensure they conform to EMVCo security guidelines, including firmware and software routines required to access the security functions of the IC.  Individual payment brands – American Express, Discover, JCB, MasterCard, and Visa – evaluate the security of their payment applications, including the native OS, EMV application and card personalization.

These evaluations, which are performed by recognized external security laboratories, provide a high level of assurance that the security functions deal with known attack methods and result in a dated EMVCO Compliance Certificate specifying traceability from manufacturer to issuer.

4.3.1 EMV Chip Applications and AIDs The chip or card application refers to a software application that resides on a chip card (e.g., MasterCard Mchip, Visa VSDC, Discover D-PAS). Processing values and parameters that are associated with a particular application are stored in the chip. Although some parameters may be shared between multiple applications, many parameters have unique values for different applications (e.g., a debit application and credit application). Each chip application is represented by an Application Identifier, or AID. In an EMV transaction, the card will have one or more chip applications and associated AIDs and the EMV chip-enabled POS terminal will have a list of the AIDs that it supports. In the application selection process, the chip card and the terminal communicate, identify the mutually supported AIDs and applications, and select the AID for the transaction.

4.3.2 EMV Chip Data Figure 9 shows a partial list of EMV data that is stored in the EMV application on the chip. The data is frequently referred to as an EMV tag. Figure 9. Examples of EMV Data Stored in the EMV Chip27

27 EMV 101, Guy Berg, Datacard Group, presentation, “EMV Roadmap Implementation Options,” Smart Card Alliance workshop, May 2, 2011

Many of the EMV tags in Figure 9 have numerous sub-configuration options. For example, Figure 10 shows the list of options within the EMV tag 9F07 – Application Usage Control.

Figure 10. Example of EMV Options Application Usage Control

Valid for domestic cash transactions Valid for international cash transactions Valid for domestic goods Valid for international goods Valid for domestic services Valid for international services Valid at ATMs Valid at terminals other than ATMs Domestic cashback allowed International cashback allowed

4.4 EMV Changes to the Messaging Infrastructure With EMV, the payments industry is moving towards global interoperability with chip technology that provides form factor flexibility with value-added service capabilities and increased security. The EMV payments infrastructure includes a new network message field that transports chip data. In the U.S., this field is often referred to as Field 55. Outside of the U.S., the data is sometimes carried in a bitmap format known as “third bitmap.” Field 55 is a generic, flexible, variable length container that conforms to tag-length-value (TLV) encoding. Every data element carried in the field has a specific tag, followed by the length of the data and then the actual data. Each tag is defined by EMV or specified in the relevant payment brand specifications. The authorization request cryptogram, the terminal unpredictable number, the transaction amount, and the form factor indicator are typical of the types of data passed in this field. Field 23 carries the card sequence number. When two or more cards are associated with a single account number, this field contains the number assigned to a specific card. For example, there are some situations (such as families) where a single primary account number (PAN) is used by different cardholders. For these cards, the card sequence number identifies the individual card sending chip data in the authorized message. Issuers, acquirers, and merchants all need to change their infrastructure to support Field 55 in the authorization request and response messages and Field 23.28

28 Messaging requirements should be discussed with the payment brands to ensure that all required messaging changes are considered in implementation.

Table 4. Field 55 Common Tag Values

Tag Tag Descriptor Functionality Details

9F26 Application cryptogram Card authentication Contains the cryptogram used to authenticate the transaction.

9F36 Application transaction Card authentication Contains the value of the POS terminal sequence counter transaction sequence counter. The POS terminal maintains a transaction sequence counter and increments the count each time a transaction is initiated.

9F07 Application usage control Card authentication Specifies the issuer’s restrictions on the geographic usage and services allowed for the application.*

9F27 Cryptogram information Card authentication Indicates the type of cryptogram and the data actions to be performed by the terminal.

9F34 CVM results Cardholder verification Identifies how the cardholder was verified at the POS: by cardholder signature, cardholder PIN, or verification not required.

9F0D Issuer action code— Transaction authorization Specifies issuer conditions that cause a default transaction to be rejected if the transaction might have been approved online but the terminal is unable to process it online.*

9F0E Issuer action code— Transaction authorization Specifies issuer conditions that cause a denial transaction to be denied without an attempt to go online.*

9F0F Issuer action code— Transaction authorization Specifies issuer conditions that cause a online transaction to be transmitted online.*

9F10 Issuer application data Card authentication Contains issuer application data transmitted from the chip to the issuer. Is updated by the issuer in the response message.

9F37 Unpredictable number Card authentication Contains the POS terminal unpredictable number value. POS terminal generates the number value that may be used as input to the application cryptogram algorithm. *http://www.emvlab.org/emvtags/all

Table 5. Field 23, Card Sequence Number

Field Descriptor Functionality Details

23 Card sequence number Card authentication Contains a card sequence number from the EMV card chip that identifies to the issuer which card was used at the POS when multiple cards are associated with the same primary account number.

4.5 EMV Migration Options EMV migration is a system migration. The new application and capability on the chip must work in conjunction with the terminals, the acquiring systems and the issuer host authorization system in order to leverage the full advantage of EMV. Many interconnected factors and developments must be considered to construct an EMV migration plan, including the current contactless implementation, use of contact and/or contactless EMV, selection of options from the EMV standard to suit the market environment, convergence with NFC mobile contactless payments, and the use of a PIN as opposed to a signature CVM. The next sections review the critical EMV options that issuers, acquirers/processors, merchants/merchant POS providers, and ATM providers need to consider when migrating to EMV. Planning for EMV implementation requires choices in four areas: 1. Card interface 2. Card authentication method 3. Transaction authorization 4. Cardholder verification method While each choice must be made independently, some are interconnected, and some choices may vary dynamically depending on the circumstances. Table 6 summarizes the implementation options. Table 6. Implementation Options

Implementation Option Description

1. Card Interface a) Contact  Standard EMV chip card. Contact  Requires contact reader.

b) Contactless  RF card, NFC on a mobile phone, or various form factors, including stickers.  Requires contactless reader.  Leverages second-generation contactless cards being deployed in the U.S. and Canada.

c) Dual interface  Card containing both contact and contactless interfaces.  Works with either contact or contactless reader.

Implementation Option Description

2. Card a) Online only  Uses 8-byte Triple DES cryptogram. Authentication  No requirement for SDA, DDA, or PKI cryptographic co- processor.*

b) Offline  Uses SDA, DDA and/or CDA and PKI.  Requirement for PKI cryptographic co-processor (for DDA and CDA only).

3. Transaction a) Online  Authorization message sent to issuer as currently Authorization implemented for magnetic stripe card transactions.

b) Offline  Authorization determined by EMV risk assessment and preferring communication between card and terminal.  May be forced online, depending on limits and other factors.

4. Cardholder a) Signature  No special POS requirement. Verification b) Online PIN  Requires POS PIN pad.

c) Offline PIN§  Requires POS PIN pad.  Uses SDA for plain text PIN, and/or DDA or CDA and PKI for enciphered PIN.  Requirement for PKI cryptographic co-processor (for DDA and CDA only).

d) No CVM  No special POS requirement.  Usually reserved for low value transactions.

* All microprocessor cards used for EMV include a DES cryptography engine. DES cryptography is employed as a core part of chip security and is used in the personalization process and in any post- issuance EMV scripts from the issuer that are used to change EMV settings on the card. § Offline PIN can be either enciphered or plain text.

4.5.1 Card Interface Options Each of the three card interface options, contact, contactless, or dual-interface, has advantages and disadvantages for industry stakeholders in an EMV migration.  The contact interface requires the issuance of contact chip cards and the installation of contact chip readers at merchants and ATMs. Contact EMV card security features cannot be used with today’s contactless POS readers.  The contactless interface provides a bridge to implementation of NFC-enabled mobile contactless payments.  Dual-interface cards carry both contactless and contact EMV interfaces. Selecting a dual interface card allows the same card to be used both at contactless POS readers and contact readers. For the foreseeable future, all cards will continue to carry a magnetic stripe to ensure acceptance in regions without EMV and for facilitating fallback to magnetic stripe.

4.5.2 Card Authentication and Transaction Authorization Options Online card authentication and online transaction authorization together are known as “online EMV,” a streamlined implementation with 100 percent online authentication that is compatible with EMV deployments everywhere. Online EMV may be appropriate for countries with a fast, reliable telecommunications infrastructure, such as the U.S. For online authentication, the EMV standard specifies that the card generate an 8-byte cryptogram using Triple Data Encryption Standard (TDES)29 symmetric keys, rather than using the more complex RSA30 public key infrastructure. Online EMV implementation does not need to support SDA, DDA, or offline PIN. This implementation avoids the additional cost of cards with crypto co-processors to support DDA or CDA, certificate authorities, and PKI support in POS terminals. Implementation of Online EMV, especially if contactless, leverages the industry’s investment in contactless terminals,31 contactless cards, and implementation of new fields in the authorization message to carry the 8- byte cryptogram and related chip data. These cost savings should be a factor when comparing the cost of implementing online EMV to the cost of implementing offline-capable EMV. Another option is to implement offline-capable EMV but require the majority of transactions to be online. For example, in Canada, only a few acquirers are offline-capable. The others are “online preferring” and set floor limits to zero, in effect forcing all transactions online. However, POS terminals installed at Canadian merchants all support the full complement of SDA, DDA, and CDA.

4.5.3 Cardholder Verification The choice of cardholder verification methods – online PIN, offline PIN, signature, or no CVM – is more straightforward. (See Section 4.1.2 for additional details on EMV cardholder verification methods.) Selecting signature verification avoids the requirement to install PIN pads and eliminates certain cardholder behavioral change and training requirements. Selecting the PIN option requires the installation of PIN pads at merchant locations. The choice of PIN also impacts the EMV authorization process for issuers and acquirers/processors (which is discussed in Sections 4.6 and 4.7, respectively).

4.5.4 Hybrid Options EMV implementation may combine options, depending on venue and transaction type. Depending on what product is being offered, individual issuers might choose to implement multiple approaches, the acquirer infrastructure will support all of them, and merchants will choose which EMV features they want to support. This is the situation in most markets today, as well as in the current U.S. environment with magnetic stripe for cardholder verification. A hybrid solution could incorporate the benefits available with all of the options, leverage the existing contactless infrastructure, and ensure compatibility with cards from the rest of the world. While at first glance this solution may appear complicated, the flexibility it offers would ease the transition to EMV by accommodating unique merchant, venue, and issuer objectives.

29 Triple Data Encryption Standard (TDES) block cipher applies the DES cipher algorithm three times to each data block. For further information, see http://en.wikipedia.org/wiki/Triple_des 30 RSA is an algorithm for public-key cryptography. For further information, see http://en.wikipedia.org/wiki/Rsa and http://en.wikipedia.org/wiki/Public_key_infrastructure 31 Most contactless terminals deployed in the U.S. operate in contactless MSD mode today. To become EMV-capable, these readers typically require a firmware upgrade, including an EMV Level 2 software kernel, and application upgrades. Whether upgrading can be done remotely depends on the terminal management system and its capability for remote downloads. Without remote upgrade capability, a reader may have to be returned to the manufacturer for refit.

4.5.5 EMV Infrastructure and Migration Changes to all of the major infrastructure components – the card, terminal, acquiring system and host authorization system – are required to leverage the full security of the EMV application placed on a smart card. Sections 4.6, 4.7, 4.8 and 4.10 will discuss the changes required for each of the infrastructure components for the card issuer, acquirer/processor, merchant POS system and ATM system to migrate from a magnetic stripe infrastructure to an EMV infrastructure.

4.6 Card Issuer Migration Considerations EMV provides a variety of options that support implementation flexibility; an issuer can implement only the options that best fit the issuer’s needs and marketplace. This section discusses the issuer implications for selecting particular implementation options in five key areas: the card (chip) interface, the cardholder verification method, the personalization system, the host system, and the transaction authorization process.

4.6.1 Card Interface One of the first decisions an issuer must make in deploying EMV is to decide on the card interface: contact, contactless, or dual. This decision would be based on the individual issuer's goals and objectives for issuance and business plan. The interface decision will also help determine the associated payment brand EMV application that will be personalized on the card to support contact, contactless or dual-interface chip cards. Key considerations in this decision are the target customers and products for EMV migration.  Contact cards and readers are widely deployed in markets outside of the U.S. To enable cardholders to use EMV payment cards globally, a contact EMV card would provide global acceptance. As of early 2015, the majority of EMV chip cards being issued in the U.S. are contact chip cards and merchant POS installations support contact chip.  For contactless payments, the U.S. reader infrastructure deployment is currently based on contactless magnetic stripe data (MSD, a contactless implementation that leveraged the magnetic stripe infrastructure), while the emerging Canadian and European contactless infrastructures are based on contactless EMV. Issuers will need to determine whether to support contactless MSD, contactless EMV, or both. A contactless MSD card may not work with a European contactless EMV terminal (and vice versa), unless the terminal supports both. (Additional information on contactless MSD can be found in Section 5.1.2.)  Dual-interface cards supporting both contact and contactless interface would enable the broadest acceptance, but incurs additional cost for supporting both interfaces.

4.6.2 Offline PIN vs. Online PIN As discussed in the Section 4.1.2.1, the offline PIN is distinct and separate from online PIN and is deployed at the POS. For U.S. issuers, the cost and complexity of an overall offline PIN infrastructure should be evaluated because this infrastructure does not currently exist. Offline PIN can be supported in two ways, either a plain text offline PIN or an enciphered offline PIN. Enciphered offline PIN requires PKI support and a card with a cryptographic co-processor. These elements can add to the cost of the card and require additional system support. Additionally, the issuer needs to be able to manage the offline PIN for basic servicing such as PIN resets and unlocks. This type of servicing requires the ability to support issuer EMV scripts. An issuer should consider how these scripts can be delivered to the card, such as through an in- person branch visit or through the ATM network. For cardholder convenience and ease of use,

synchronization between the offline PIN and online PIN may require additional resources and considerations.

4.6.3 Personalization System When preparing to issue EMV cards, issuers need to consider the hardware, software and issuance process implications. Issuance of EMV cards requires additional software and a hardware security module (HSM) for EMV data preparation and key management at the data center and additional hardware and software to be added to the central issuance personalization equipment. The EMV data preparation and key management applications provide the ability to configure EMV tags and prepare both the EMV tags and cryptographic keys for loading to the chip. EMV tags are the EMV configuration parameters that convey the issuer's EMV implementation choices to the EMV application on the chip. The cryptographic keys are integral to EMV authentication security and to secure EMV script updates after the card is issued and in the hands of cardholders. Both the data preparation and the key management applications require an HSM to generate, store and process the EMV cryptographic keys during the data preparation process. The applications can share the same HSM or use separate HSMs. The EMV data preparation and key management applications can be installed in the issuer’s secure data center or issuers can outsource this functionality to a full service personalization bureau that already has them installed and audited by the payment brands that they support. The central personalization equipment must also add support for chip personalization. If the issuer, or the service bureau, has not yet added support for chip card personalization to their issuing equipment they will need to purchase an IC module upgrade for their existing equipment or may have to purchase new central issuance equipment with chip personalization capability. A chip personalization module can be purchased with either contact or contactless support, and in some cases, one module can support both contact and contactless chips. The personalization equipment provider can recommend the best personalization module configuration based on the issuer’s objectives. An HSM and special EMV personalization software that interfaces to the personalization equipment is also required to support chip programming through the central issuance equipment. HSMs are used to store cryptographic keys, derive keys during personalization, and secure the personalization communication lines.

4.6.4 Host System For issuers (or processors) to support chip cards, they must process full chip data or use the data processing service from a payment brand. The service is commonly called the "early chip data option,” and is available for processing both contact and contactless data. The "early chip data option" provides an issuer with the flexibility to process chip cards initially while making the needed changes to support Field 55 and Field 23 for full chip data migration. Most of the processing validates the authorization request cryptogram and, if needed, generates an authorization response cryptogram to send back to the chip. To validate the cryptogram, the issuer or processor must hold the symmetric key used by the card. The chip data is then used to recalculate the cryptogram value and match it to the value calculated by the card. This process, known as card authentication method validation, is a powerful deterrent to the creation of counterfeit cards. The "early chip data option" requires the issuer or processor to make few or no changes to the host system, thereby reducing initial implementation expense and potentially speeding up deployment. The disadvantages of selecting this option include reduced issuer visibility at the point of transaction (e.g., the issuer will not get the full chip data in Field 55; however, they are

provided with the cryptogram validation results) and limited flexibility in making changes on the chip such as unlocking and changing an offline PIN through issuer scripting. The full chip data option requires changes to the host system to process chip transaction data. The benefits of this approach include greater issuer visibility at the point of transaction and immediate flexibility in being able to block applications. However, this approach implies that the issuer will incur the cost associated with changing the host system.

4.6.5 Transaction Authorization Process Issuers are typically migrating from a magnetic stripe card environment. The existing transaction authorization process therefore typically relies on static data to authenticate transactions and online networks to authorize transactions based on risk parameters. Today, a cardholder swipes a magnetic stripe card at a merchant terminal, the track 1 or 2 data is captured, and the transaction is sent to an acquirer, routed to the appropriate payment brand/network, and ultimately sent to an issuer for authentication and authorization. The issuer validates the track data and determines the authenticity of the card based on the static CVV/CVC/CID data element within the track. Once the card is authenticated, the issuer applies its risk parameters and uses fraud neural networks and the online PIN result (if appropriate) to determine the authorization response. The EMV transaction authorization process relies on dynamic data to authenticate transactions, and certain risk parameters can be managed by the issuer within the card. In an EMV scenario, a cardholder inserts an EMV card into the reader, and the merchant POS terminal identifies which payment brand application is on the card so the terminal uses the appropriate payment brand application protocols. Once an application is selected, the card and terminal enter into a dialog to identify the risk management process and determine whether the transaction should be performed offline or online. An issuer can use the card profile to implement whether and when a transaction must go online or offline. If offline transaction processing is implemented by an issuer, a variety of offline features must be considered, such as offline data authorization controls, offline data authentication, and online or offline CVMs. If online transaction processing is implemented by an issuer, the card supports online card authentication and online or offline cardholder verification methods. For online card authentication, the chip generates the EMV cryptogram (the ARQC). Track 2 equivalent data, the ARQC, and potentially the CVM’s online encrypted PIN or offline PIN comparison results are sent in the authorization message. The issuer validates the authorization message and authenticity of the card based on the ARQC. Issuers need to add an HSM on the authorization system to perform the EMV cryptogram (ARQC) validation and to send back to the terminal an Authorization ResPonse Cryptogram (ARPC) The issuer can also use the offline and online risk management results to determine the authorization response.

4.6.6 Summary Table 7 summarizes considerations for issuers.

Table 7. Issuer Considerations

Implementation Option Consideration

1. Card Interface a) Contact  Contact cards and readers are widely deployed in markets Contact outside of the U.S. In the U.S., early EMV chip card issuance has been contact cards and early merchant deployments have been contact chip POS terminals.

b) Contactless  Contactless cards and readers are not widely deployed

Implementation Option Consideration

globally, but some U.S. and Canadian issuers have adopted the technology, and European issuance is expected to increase.  Issuers will need to determine whether to support contactless MSD, contactless EMV, or both. At this time, some early contactless MSD cards may not be accepted outside of the U.S.

c) Dual interface  Supporting both interfaces incurs additional costs.

2. Card a) Online  Issuers must choose whether to validate card data on their own Authentication or allow card brands to validate on their behalf.

b) Offline  Issuers must choose whether to allow the card to authenticate chip data. SDA or DDA can be used by the issuer.  Supporting the public key infrastructure incurs additional costs.

3. Transaction a) Online  Issuers must choose whether to receive full chip data or early Authorization chip data.

b) Offline  Issuers can apply various risk parameters to allow the EMV chip to authorize transactions offline on their behalf. Risk parameters may include checking transaction amount limits and the number of consecutive offline transactions before requiring an online authorization to be performed.  Offline authorization also affects transactions downstream.  Issuers will need to modify their clearing and settlement systems to receive additional chip data (generally in the same format as Field 55 in the authorization request). Clearing and settlement systems should be modified to allow for easy identification of offline transactions vs. online transactions.

4. Cardholder a) Signature  Signature is included in the CVM list on the chip unless Verification otherwise specified by the payment brands.

b) Online PIN  Issuers can include online PIN in the CVM list. The online PIN infrastructure will need to be supported by issuer. ATMs only support online PIN.

c) Offline PIN  Issuers can include offline PIN in the CVM list. The offline PIN infrastructure will need to be supported by the issuer for PIN management.  Issuers should be aware that the offline PIN may differ from the online PIN; therefore, PIN management is critical to avoid cardholder confusion. It is strongly recommended that the offline PIN and online PIN be synchronized to prevent cardholder confusion.  Issuers will need to support Field 55 through full chip data processing in order to perform issuer scripting for unlocking and changing offline PIN.  Supporting the offline PIN infrastructure incurs additional costs.

d) No CVM  No CVM is included in the CVM list unless otherwise specified by the payment brands.

4.7 Payments Acquirer/Processor Considerations Current magnetic stripe platforms operate in both the dual- and single-message format environments. A POS device or card-not-present merchant system transmits transaction messages for authorization or approval to the acquiring processor or, in some cases, directly to the payment brand network. These messages include, but are not limited to, cardholder track data and cardholder PIN for PIN debit transactions when a card is swiped, or primary account number (PAN) and expiration date if the card is key entered (PIN debit transactions can only be swiped). Additional data can be submitted with the transaction message for card-not-present transactions to assist merchants in preventing fraud (e.g., CVV2/CVC2 or AVS data). The messages are based on proprietary message systems and ISO/IEC 8583 standard. Magnetic stripe data must not be stored after authorization. In the dual-message process, only the PAN and expiration date are retained by the merchant processor to create the settlement record. The authorization response data indicates the presence of magnetic stripe data at the POS. The PIN is never retained and must always be encrypted using Triple DES encryption. The next sections describe the changes to this acquiring/processing infrastructure that are required to support contactless MSD, contactless EMV and contact EMV transactions.

4.7.1 Contactless MSD For a contactless MSD transaction, the message from the POS device or merchant host system to the processor or payment brand network is basically the same as the message sent when the transaction is initiated by swiping the card. The differences are:  The values sent in the POS Entry Mode and Terminal Capability fields. These fields contain values that identify the POS entry method used to capture the cardholder data and whether the terminal is capable of reading a chip.  The dynamic card verification value/code (dCVV/CVC3), which is passed in the message in the same field that was used for the original card verification value, and the application transaction counter (ATC), which is passed in the area reserved on the track layout for issuer discretionary data. The contactless chip provides the magnetic stripe equivalent data to the POS terminal through the RF interface. Terminal vendors and software providers must certify that they will transmit the appropriate fields to the processors for contactless transactions. Processors must certify that they will transmit the appropriate fields to the payment brand networks.

4.7.2 Contactless EMV In a contactless EMV transaction, presenting the contactless card to the POS device sends the chip data from the card to the POS device. The processor must be able to receive all possible types of chip data from the POS device and place the data in the appropriate Field 55 tags and in any custom tags used by a particular payment brand. In addition, processors will need to support new fields and values to identify the POS entry method and the card sequence number (Field 23) when obtained from the chip. Terminal vendors and software providers must certify that they will transmit the fields appropriate to contactless EMV transactions to the processors. Processors must certify that they will transmit the appropriate fields to the payment brand networks. Processors must update systems to store the appropriate data from Field 55. Settlement systems must be updated to support required

data from Fields 55 and 23 in the clearing records for submission to the payment brand networks, to ensure proper interchange qualification and support new interchange categories.

4.7.3 Contact EMV with Signature or PIN The changes required by contactless EMV transactions are also required by contact EMV transactions, with the exception that the chip data is only retrieved by the chip reader or the "dip." When the transaction requires a PIN, the PIN is validated using an offline plain text PIN (sending the unencrypted PIN to the card), an offline enciphered PIN (encrypting the PIN entered before sending it to the card), or an online enciphered PIN (encrypting the PIN entered before sending it online to the card issuer). For the online enciphered PIN, the processor must be able to support receiving the encrypted PIN and passing this encrypted PIN to the payment brand network.

4.7.4 Summary For all EMV processing, processors must be able to receive application response cryptogram data and EMV scripting data in the response messages from the payment brand networks and pass this data to the merchant POS device. All devices and software must be certified by EMVCo and the payment brands before they can be used to process EMV transactions. Payment acquirers must decide which readers, devices, and software applications to certify and deploy, based on their merchants’ needs. Processors will need to determine operating system support capabilities and certify with the payment brands. Processors with multiple platforms will need to determine each system’s capabilities; support may be limited to one platform. Table 8 summarizes considerations for payments acquirers and processors.

Table 8. Payments Acquirer/Processor Considerations

Implementation Option Consideration

1. Card Interface a) Contact  Does not support NFC mobile contactless payments. Contact  May require a PIN pad.

b) Contactless  PIN debit is not supported by Visa for contactless transactions.  Limited contactless deployment outside of the U.S. and Canada.

c) Dual interface  PIN debit is not supported by Visa for contactless transactions.  Limited contactless deployment outside of the U.S. and Canada.

2. Card a) Online  Optional fields must be supported if received from the issuer. Authentication b) Offline  Any data indicator in Field 55 that provides information about authentication will contribute to the success of the authentication.

3. Transaction a) Online  No change required. Authorization b) Offline  Most transaction types require authorization to be obtained online.

Implementation Option Consideration

 Offline authorization affects transactions downstream (interchange qualification and operating rules).

4. Cardholder a) Signature  Transactions at or below a specified amount based on Verification merchant type do not require merchants to obtain and validate the signature at the POS.

b) Online PIN  If online PIN for credit card transactions is required, then credit card processing must change to accommodate the online PIN.  Requires a PIN pad.

c) Offline PIN  Processors will need to support Field 55 to identify the result of offline PIN validation.  Requires a PIN pad.

d) No CVM  Terminals must be configured to not request a PIN or signature at the POS if the chip does not require cardholder verification.

4.8 POS Terminal and Merchant POS System Considerations The capabilities of the POS terminal play a pivotal role in the success of any payment innovations. Issuers can distribute cards and other payment devices with new functions (such as sophisticated fraud prevention or customer convenience and marketing functions), but the cards are doomed to fail if retailer POS terminals cannot support the innovations. Even the adoption of magnetic stripe technology took years, primarily because of the amount of time it took for appropriate POS terminals to be widely deployed. In the current era of rapid technology innovation, terminal capabilities will have increasing influence over the success of new payment innovations. Merchant terminals need to migrate to support contactless EMV, contact EMV, and NFC applications. Given all of these possibilities, it is important to consider the following parameters:  Hardware support  Software support  EMV and brand certification  Transaction messaging support  Terminal software upgrade capabilities and plans

4.8.1 Hardware Support To support EMV cards, a terminal needs a contact EMV card interface device (CID) to read the contact EMV card and a contactless reader that supports the ISO/IEC 14443 standard. The hardware components must be certified by EMVCo. This is referred to as an EMVCo Level 1 Certification. Contactless MSD, contactless EMV, and NFC mobile contactless payment all use ISO/IEC 14443. However, all terminals with a contactless reader that is ISO/IEC 14443-compliant cannot necessarily accept all of these types of payments. The terminals must also include software or firmware that supports the contactless applications used by a particular brand or NFC device.

This is an important consideration when evaluating terminals and requires an understanding of terminal software and certification requirements.

4.8.2 Software Support The terminal must support the new decision process that is conducted between the card and the terminal to perform both the card and terminal authentication process, and the risk management assessment must be programmed into the terminal. At a high level, Figure 11 shows the steps that are followed by the terminal software in an EMV transaction. Figure 11. Steps Followed by Terminal Software in an EMV Transaction

POS terminal software is more complex than hardware, because it varies among payment brands. Figure 12 is a simplified view of the POS terminal software components. Figure 12. Simplified View of POS Terminal Software Components

Brand contact EMV logic Brand contactless EMV logic Brand contactless MSD logic EMV kernel Magnetic stripe logic

Terminal Operating System

The EMV functions that are required on the terminal are frequently referred to as the EMV kernel. The EMV kernel provides the payment terminal’s EMV foundation logic. The brand contact EMV logic and brand contactless logic leverage the EMV kernel, but also incorporate brand-specific EMV processing options. EMV provides multiple implementation options for payment. Each payment brand has implemented the EMV standards differently, and a terminal requires specific software logic for each implementation. Because EMV supports implementation flexibility, POS application vendors must have their applications certified by each payment brand before the applications are approved for use in the market. Accordingly, it is important to understand what payment brand certification approvals the terminal and terminal applications have received. Terminal application certification can be a lengthy process. Many terminal providers offer terminals that have been certified at a minimum by both MasterCard and Visa.

The contactless MSD logic is not an EMV implementation but was designed to leverage the current magnetic stripe infrastructure and messaging. This is why add-on contactless readers can be attached to a magnetic stripe POS terminal without requiring EMV logic or certifications. Figure 13 illustrates the relationship between application logic and each chip payment type.

Figure 13. Detailed View of POS Terminal Software Components

Contactless Visa EMV MC EMV Discover EMV Amex EMV EMV

Contact Visa EMV MC EMV Discover EMV Amex EMV U.S. MSD Visa MasterCard Discover Amex EMV Contactless

EMV kernel Magnetic stripe logic

Terminal operating system

The POS terminal does not require specific logic for NFC mobile contactless payments as long as the NFC payment application on the handset emulates a payment brand's contactless EMV or contactless MSD transaction. To avoid imposing new terminal requirements strictly for NFC, NFC applications are leveraging the contactless infrastructure defined for EMV contactless or MSD contactless. In addition to the internal transaction logic, EMV and each of the payment brands may have terminal prompt and receipt printing requirements. Finally the terminal must package the EMV cryptogram that is sent to the host for authentication and the EMV data elements shown in Figure 14 in the transaction data. Figure 14. EMV Transaction Data Elements

These changes in the terminal application are frequently referred to as Level 2 application changes by EMVCo and EMVCo has defined a specific set of tests that terminals must pass to obtain EMV certification. These tests are referred to as EMV Level 2 Certification tests.

4.8.3 EMV and Brand Certification EMV contact and contactless terminals require multiple certifications. The first certification is EMV certification. To achieve this certification, the terminals must be submitted for lab testing to

verify that all of the EMV kernel functions are operating correctly. EMV certification means that the terminal meets the baseline EMV specification requirements. After receiving EMV certification, a terminal must receive brand certification. The terminal must pass a specific and unique set of tests defined by the payment brand network. When considering the deployment of EMV-compliant terminals, it is important to be sure that the terminals are certified by each of the brands. There are terminal certification requirements that apply to both contact and contactless EMV. It is critical for merchants to make sure that the terminals purchased have current certifications for all capabilities that need to be supported and each of the payment brands that they accept. POS Configuration Not all terminals from a particular terminal brand have the same software support and EMV and brand certifications. Multiple POS configurations are possible:  Standalone terminals Standalone terminals are not connected to any other cash register system. A standalone terminal can support EMV as long as the acquirer or independent sales organization (ISO) supports EMV messaging. The terminal vendors themselves may write the EMV terminal application that supports a particular brand.  Integrated POS systems Large retailers often have their own customized cash register software systems with all or portions of the debit and credit card processing logic built in. To support contact EMV, contactless MSD, contactless EMV, or NFC mobile contactless payments, these systems will need additional logic or alterations to leverage the logic in an attached brand-certified terminal.  Value-added service provider terminals These terminals are provided with customized software developed as part of an ISO, acquirer, or terminal reseller service offering.

4.8.4 Transaction Messaging Support Figure 15 shows the communication path between the POS terminal and the issuer’s host system. The standard EMV message format for communication between the issuer’s host processing systems and the acquirer is defined by Field 55 (see Section 4.4) and ISO/IEC 8583 standard. Communication between the terminal and the acquirer is not standardized. Figure 15. Communication from Host to Acquirer to Terminal

To support online EMV only, at a minimum the field that carries the cryptogram would need to be increased in size in both segments A and B of the messaging illustrated in Figure 15. To support the full EMV messaging specification, which means to support all of the Field 55 and Field 23 EMV data elements, both segments A and B would need to be modified. Changing the messaging in segment B requires changes to the terminal application logic and the acquiring host system. End-to-end encryption, the Payment Card Industry Data Security Standard (PCI DSS) and tokenization are three other initiatives that merchants are implementing, which also affect the

payment transaction infrastructure and processes. Implementing each initiative in isolation suggests separate development and POS terminal application release efforts. Entities that are initiating development in these areas are encouraged to implement the messaging changes that support full EMV messaging, even though the fields may not be used immediately.

4.8.5 Terminal Upgrade Capabilities and Plans Merchants should be sure that their acquirer and terminals support remote terminal management and application upgrade. The state of contact and contactless chip payment adoption is still in flux in many markets, including the U.S. For this reason, acquirers may offer terminals that include the hardware to support contact EMV or contactless EMV payments but that do not include EMV applications. These terminals are designed to facilitate remote application downloads and updates and have received brand-level certifications for EMV applications that can be downloaded in the future. If an acquirer plans to buy an upgrade that supports EMV, the acquirer must assure the merchant that the upgrade has been certified by the payment brands for the merchant’s specific terminal model. When evaluating POS terminal deployment options, terminal upgrades provide a potentially cost-effective approach to managing the market’s uncertainties. However, when evaluating this approach, it is important to consider the acquirer’s software upgrade costs and deployment strategies.

4.8.6 Summary The terminal migration is tightly coupled with merchant support strategies for each acquirer and ISO in the marketplace. Acquirers and ISOs assess the demand for features and functions demanded by their customers and are required to implement the EMV application logic and messaging changes described to support EMV. In addition, these organizations are responsible for selling terminals that can meet merchant needs for the next 3–5 years. A large part of their investment lies in brand-level EMV application development and certification. However, terminals are available that have the required certifications, and leading acquirers are installing terminals with the hardware to support contact and contactless EMV transactions. In some cases, these acquirers are activating contact EMV and contactless EMV support; in other cases, they are prepared to download the EMV upgrades as needed. Table 9 summarizes POS terminal and system acquisition considerations.

Table 9. POS Terminal and System Considerations

Implementation Option Consideration

1. Card Interface a) Contact  The terminal must have a contact chip reader and be loaded Contact with application software that supports EMV transactions for each of the payment brands.  The terminal should be certified by EMVCo and by each payment brand for which EMV cards will be accepted. The acquirer typically assumes responsibility for obtaining the certifications.

b) Contactless  The terminal must have a contactless reader and be loaded with an application that can support contactless MSD transactions, contactless EMV transactions, or both.  The terminal should be certified by EMVCo and by each payment brand for which EMV cards will be accepted. The acquirer typically assumes responsibility for obtaining the certifications.

Implementation Option Consideration

c) Dual interface  The terminal must have either a contact or contactless chip reader and must be loaded with application software that supports EMV transactions for each of the payment brands.  The terminal should be certified by EMVCo and by each payment brand for which EMV cards will be accepted. The acquirer typically assumes responsibility for obtaining the certifications.  The terminal must have a contactless reader and must be loaded with an application that can support either contactless MSD transactions, contactless EMV transactions, or both.

2. Card a) Online  The terminal application must be certified by EMVCo and by Authentication each payment brand to assure that it follows the specific transaction process defined by each payment scheme. The acquirer typically assumes responsibility for obtaining the certifications. One certification process covers both online and offline.  The acquirer typically also must obtain a brand network certification. The terminals should be ready to support SDA, DDA, and CDA and online authentication cryptogram.

b) Offline  The terminal application must be certified with EMVCo and each payment brand to assure that it follows the specific transaction process defined by each payment brand. The acquirer typically assumes responsibility for obtaining the certifications. One certification process covers both online and offline.  The acquirer typically also must obtain a brand network certification. The terminals should be ready to support SDA, DDA, CDA, and online authentication cryptogram.

3. Transaction a) Online  POS terminals and systems must support Field 55 for both Authorization authorization and clearing. The terminal application must be certified by EMVCo and each payment brand to assure that it follows the specific transaction process defined by each payment brand. The acquirer typically assumes responsibility for obtaining the certifications. One certification process covers both online and offline.  The acquirer typically also must obtain a brand network certification.

b) Offline  POS terminals and systems must support Field 55 for clearing only. The terminal application must be certified by EMVCo and each payment brand to assure that it follows the specific transaction process defined by each payment brand. The acquirer typically assumes responsibility for obtaining the certifications. One certification process covers both online and offline.  The acquirer typically must also obtain a brand network certification.

4. Cardholder a) Signature  No change required.

Implementation Option Consideration

Verification b) Online PIN  The terminal must support PIN entry or support a connected PIN pad.

c) Offline PIN  The terminal must support PIN entry or support a connected PIN pad with a smart card reader.

d) No CVM  No change required.  The terminal needs to be able support "no CVM" according to the payment brand rules.

4.9 U.S. EMV Debit The U.S. has unique regulatory requirements for debit payments that required a U.S. regional solution for EMV debit implementation. Regulation II of the Durbin Amendment to the Dodd- Frank Wall Street Reform and Consumer Protection Act of 2010 (“Reg II”) contains two provisions that impact the implementation of EMV in the U.S. debit card payment environment.32  Debit card issuers are required to support two competing debit networks on their cards. One network may be the card brand on the face of the card, and the other network must be unaffiliated with that card brand. With EMV this requires an additional application on the card’s chip.  Merchants must be allowed to route debit transactions to the debit network of their choice in order to take advantage of possible business agreements. Since transaction routing to multiple networks from a point-of-sale is problematic, such routing is generally done at the merchant acquirer’s switch. This requires that the competing network’s application on the card and payment acceptance device be compatible with whatever network the merchant prefers. The EMV Migration Forum defined a technical proposal outlining an application framework utilizing a U.S. common debit AID that allows Reg II-compliant EMV debit to be implemented in the U.S. The approach has been adopted by the industry and is now being implemented. Five U.S. common debit AID solutions are offered for licensing by U.S. regional debit networks. Available U.S. common debit AIDs are:  MasterCard international AID + Maestro U.S. common debit AID based on MasterCard M/Chip 4 or Advance and PayPass based EMV application.  Visa international AID + Visa U.S. common debit AID based on VISA VIS 1.4/1.5 and VCPS 2.1 based EMV application  Discover DPAS AID, plus Discover Debit Common Card AID.  Any AID, plus the Debit Network Alliance U.S. common debit AID based on any number of DNA approved EMV compliant application(s)  China UnionPay common debit AID U.S. EMV debit cards have two applications/AIDs on the debit chip card that connect to the same funding account. One will be a global AID for the payment network brand on the card; this AID can be used for both domestic U.S. transactions and for transactions outside of the U.S., with transaction routed to the global payment network. U.S. EMV debit cards will also have a U.S. common debit AID. When the POS terminal selects the U.S. common debit AID, the merchant can choose to route the transaction to any U.S.

32 EMV Migration Forum. “EMV Debit 101” presentation by Allen Friedman, Ingenico, March 2015

regional debit network that is supported by the card issuer and that has licensed that U.S. common debit AID solution. Additional information on the U.S. debit EMV technical approach can be found in the EMV Migration Forum’s white paper, “U.S. Debit EMV Technical Proposal.”33

4.10 ATM Considerations ATMs have long been synonymous with quick and convenient access to cash. The simplicity and ubiquity of these devices also make them a prime target for fraud. Because one of an EMV card’s key features is the inclusion of a secure chip, supporting EMV cards at ATMs would require widespread change. Nevertheless, there are compelling reasons for the financial services industry to adopt the use of EMV cards at ATMs. As a result of countries implementing EMV, ATM fraud (such as ATM skimming) is migrating from countries implementing EMV to areas that are not currently EMV enabled. The use of EMV chip and PIN cards reduced ATM fraud by 36 percent in Europe in 2009 compared with 2008, according to the European Payment Council34. ATM owners, banks, and ISOs, in conjunction with their providers, will want to review carefully the equipment they have in place. Because ATMs are typically on a 7-year upgrade or replacement cycle, a significant portion of the installed base will need to be visited during a transition to EMV. Because online PIN verification is mandatory for ATMs, the implementation option will have fewer variations. In addition to magnetic stripe cards, the ATM terminals may now need to support contactless MSD cards, contactless EMV, contact EMV, and NFC mobile contactless payments. While support for fully inserted cards has been the typical focus of initial ATM EMV conversions, new contactless options are available. ATMs must therefore be examined for the following:  Hardware capabilities  Software capabilities  EMV and brand certifications  Terminal software upgrade capabilities and plans

4.10.1 ATM Hardware Required ATM hardware includes several components. An ATM needs a contact EMV CID to read a contact EMV card and a contactless reader that supports ISO/IEC 14443 for contactless transactions. An approved chip-capable reader is essential. Some ATMs may have been sold as EMV ready; however, it is essential to ensure that the installed device has been certified to the latest version of the specification or can be upgraded. In addition, an ATM must be equipped with an approved encrypting PIN pad. This feature was included in the mandatory Triple DES upgrade that took place a few years ago in the U.S.

4.10.2 ATM Software ATM software includes the software required to enable all necessary hardware functions. In addition, specific software or firmware is needed to enable the specific contactless applications supported by the cards or NFC devices used at the ATM. This is an important consideration

33 “U.S. Debit EMV Technical Proposal,” EMV Migration Forum, April 2014, http://www.emv- connection.com/u-s-debit-emv-technical-proposal/ 34 European Payments Council Report, April 2010, http://www.europeanpaymentscouncil.eu/article.cfm?articles_uuid=3EBDA5B6-CB2E-179D- 211BE1EBB4A0CE0C

when evaluating terminals, and it is helpful to understand terminal software and certification requirements. ATMs must have an approved and certified EMV kernel and support all required extensions to the messaging protocol.

4.10.3 Certifications EMV contact and contactless terminals are required to receive multiple certifications (Figure 16):  EMVCo Level 1: interface/card reader function certification  EMVCo Level 2: terminal software application function certification  Payment brand certification

Figure 16. ATM Certification Requirements

To achieve Level 1 and 2 certification, terminals must undergo lab testing to verify compliance with the electromechanical characteristics, logical interface, and transmission protocol requirements (Level 1) and the debit/credit application requirements (Level 2) defined in the EMV specifications. EMV certification guarantees that the terminal complies with the baseline EMV specification requirements. EMVCo provides only Level 1 and 2 certification. Because EMV supports so many implementation options, multiple implementations of EMV can be required on a single terminal. Each payment brand can implement the EMV standards in a slightly different way, and each brand requires specific programming on the terminal for that brand’s implementation. ATM terminals must therefore pass a set of tests defined by each payment brand to receive brand-level certification. There are also terminal certification requirements for both contact and contactless EMV. Accordingly, it is important to understand what payment brand certifications an ATM terminal and terminal applications have received. Terminal application certification can be a long process for the terminal application provider. While many of the terminal providers already have terminals that have been certified by the major payment brands, the certification transfers only if the application remains unchanged across implementations. If there are changes for a specific implementation, then a new approval process will be required for that implementation. When purchasing an ATM terminal, ensure that it has an approved software kernel and has implemented the necessary extensions to the messaging protocol.

4.10.4 Terminal Upgrade Capabilities and Plans ATM vendors report having offered EMV-capable ATMs for the past 5–7 years. Most new ATMs do not need to be replaced to accept EMV cards. ATMs have also evolved in the last 10 years from closed proprietary systems to PCs running the standard Windows® operating system. The software on modern ATMs can be upgraded easily. To protect against the uncertainty of what payment instrument types to support, ATM owners are leveraging this future upgrade capability and installing terminals with the hardware to support EMV contact or contactless transactions but without installed or activated EMV applications. These terminals are designed to facilitate remote application downloads and updates and have received brand-level certifications with EMV applications that can be downloaded in the future. Recent conversion in EMV countries, notably in the U.K. and Canada, has validated that it is also possible to upgrade ATM software for EMV functionality; however previously installed hardware requires verification that all hardware complies with the latest specification and that hardware installed earlier and having sat idle for years has not oxidized.

4.10.5 Summary Table 10 summarizes the ATM considerations. Table 10. ATM Considerations

Implementation Option Consideration

1. Card Interface a) Contact  The terminal must have a certified contact chip reader and be Contact loaded with application software that supports EMV transactions for each of the payment brands.  The terminal should be certified by EMVCo and by each payment brand for which EMV cards will be accepted. The ATM owner typically assumes responsibility for ensuring the terminal has proper certification and completing the end-to- end network certifications.

b) Contactless  The terminal must have a contactless reader and be loaded with an application that can support contactless MSD transactions, contactless EMV transactions, or both.  The terminal should be certified by EMVCo and by each payment brand for which EMV cards will be accepted. The ATM owner typically assumes responsibility for ensuring the terminal has proper certification and completing the end-to- end network certifications.

c) Dual interface  The terminal must have either a contact or contactless chip reader and must be loaded with application software that supports EMV transactions for each of the payment brands.  The terminal should be certified by EMVCo and by each payment brand for which EMV cards will be accepted. The ATM owner typically assumes responsibility for ensuring the terminal has proper certification and completing the end to end network certifications.  The terminal must have a contactless reader and must be loaded with an application that can support either contactless MSD transactions, contactless EMV transactions, or both.

2. Card a) Online  The terminal application must be certified by EMVCo and by each payment brand to assure that it follows the specific

Implementation Option Consideration

Authentication transaction process defined by each payment scheme. The ATM owner typically assumes responsibility for obtaining the certifications.  The ATM owner typically also must obtain a brand network certification. The terminals should be ready to support SDA, DDA, and CDA and online authentication cryptogram.

b) Offline  Not applicable to ATMs

3. Transaction a) Online  ATM terminals and the ATM network must support Field 55 for Authorization authorization. The terminal application must be certified by EMVCo and each payment brand to assure that it follows the specific transaction process defined by each payment brand. The ATM owner typically assumes responsibility for obtaining the certifications  The ATM owner typically also must obtain a brand network certification.

b) Offline  Not applicable to ATMs

4. Cardholder a) Signature  Not applicable to ATMs Verification b) Online PIN  The ATM terminal must support PIN entry on an encrypting PIN pad.

c) Offline PIN  Not applicable to ATMs

d) No CVM  Not applicable to ATMs

4.11 EMV and NFC Mobile Contactless Payments An anticipated area of growth in the near future is the use of Near Field Communication (NFC)- enabled mobile phones for mobile contactless payments and other mobile applications, such as coupons and loyalty.35 NFC technology is a standards-based wireless communication technology that allows data to be exchanged between devices that are a few centimeters apart.36 NFC-enabled mobile phones incorporate smart chips (called secure elements) that allow the phones to securely store the payment application and consumer account information and to use the information for payment transactions. NFC payment transactions between a mobile phone and a POS terminal use the standard ISO/IEC 14443 communication protocol currently used by EMV and U.S. contactless credit and debit cards. NFC-enabled mobile phones will be able carry one or more payment applications and accounts from different issuers; the NFC specifications don't define or specify the payment application.

35 For additional information on mobile marketing applications, see the Smart Card Alliance Payments Council white paper, Chip-Enabled Mobile Marketing, September 2010, http://www.smartcardalliance.org/pages/publications-chip-enabled-mobile-marketing. 36 For additional information on NFC, see the NFC Forum web site at http://www.nfc-forum.org. The NFC Forum defines the specifications for communication between NFC tags and readers, but does not define payment application specifications.

Payment applications will follow the payment brand specifications for the region of the world where mobile payments are being implemented.37 A contactless payment application supporting EMV transactions will be loaded in the NFC-enabled mobile phone, allowing consumers to use their NFC-enabled mobile phones for payment at the existing installed base of contactless EMV credit and debit terminals. EMVCo has been active in defining the architecture, specifications, requirements and type approval processes for supporting EMV mobile contactless payments. This has been critical in supporting the launch of NFC mobile contactless payment in Europe, which uses an EMV-based payments infrastructure. EMVCo is working with other industry groups to:38  Develop any required specifications which are specific to mobile contactless payment, and which are common across the payment brands.  Communicate requirements and provide profiles and guidelines on how architectural elements defined by other organizations are to be used in the context of mobile contactless payments in order to promote interoperability.  Develop processes to determine the level of conformance of implementations to EMVCo- defined specifications, profiles and requirements.

37 Two examples of EMV NFC trials are: NFC EMV trial in Kuwait, with National Bank of Kuwait, Visa, Zain, and ViVOtech, http://www.vivotech.com/newsroom/press_releases/NBK_Visa_Zain_Middle%20East.asp; NFC trial at the 2010 Mobile World Congress that included GSMA, Telefonica, Visa, Samsung, Giesecke & Devrient, Ingenico, ITN International and La Caixa, http://www.nearfieldcommunicationsworld.com/2010/02/15/32738/nfc-trial-begins-at-mobile-world- congress/ 38 Contactless Mobile Payment Architecture Overview, Version 1.0, EMVCo, June 2010, http://www.emvco.com/best_practices.aspx?id=162

5 Contactless Bank Card Payment Contactless payments are simply payment transactions that require no physical contact between the consumer payment device and the physical point-of-sale (POS) terminal. In a contactless payment transaction, the consumer holds the contactless card or device in close proximity (less than 2-4 inches) to the merchant POS terminal and the payment account information is communicated wirelessly (via radio frequency (RF)). This section reviews "branded" contactless payments with credit and debit cards, using payment products from American Express®, Discover® Network, MasterCard, and Visa. Contactless payments are currently supported by multiple card issuers and financial service providers. American Express, Discover Network, MasterCard, and Visa all have contactless payment products (ExpressPay from American Express®, Discover® Network D-PAS Contactless, MasterCard® PayPass™ and Visa payWave™, respectively). These products rely on ISO/IEC 14443-based technology, ensuring payment solution compatibility regardless of brand or payment device when used with contactless readers that have been approved by the payment brands. The initial introduction of contactless financial payment devices focused on markets that had lower value transactions (less than $25), where consumers used cash for payment, and where transaction speed and customer convenience were critical. Contactless payments made quick progress in many merchant segments including quick service restaurants, convenience stores, pharmacies, theaters, and sports venues. Contactless payments have expanded beyond these initial merchant segments, however, moving into other traditional retail segments (e.g., office supplies, specialty retailers, grocery stores), and opening up credit card acceptance in new merchant categories (e.g., taxis, vending machines, transit fare payment). Contactless payment can be either from a contactless or dual-interface chip card or from an NFC mobile device. (See Section 6 for additional information on mobile payments.)

5.1.1 EMV Contactless EMV contactless closely follows the EMV specifications for authentication and authorization. An EMV contactless solution may support both offline authentication and offline authorization using techniques such as SDA or DDA. In addition the EMV solution makes use of strong online authentication based on EMV standard cryptograms. Support for the EMV cryptogram requires a network change to carry the additional data required for online authentication. The primary market driver for the adoption of contactless EMV has been the ability to extend bank card payment into the micropayments transaction space. To do so requires a faster and more convenient transaction flow compared to the standard contact EMV card. The initial implementations of contactless EMV included most, if not all, of the functionality of contact EMV. However, this required the card to stay within the terminal contactless field to complete the standard EMV transaction process. This proved to be too time consuming. As a result, multiple variations of contactless EMV have evolved over the past five years. Each iteration has striven for a balance among security and risk management options, transaction speed and convenience. As a result, the transaction flow for each of the payment brands varies. The flow varies according to the extent of EMV risk management functions and type of authentication cryptogram that is implemented in the contactless application. For example, one version of contactless EMV implements a standard EMV CDA application cryptogram while another version implements a unique version of a DDA application cryptogram referred to as fDDA. In each case, the transaction flow varies. The multiple independent contactless EMV kernels required POS terminals to be approved by each payment brand. EMVCo recognized the need for standardization and developed the common contactless terminal roadmap. In Phase 1, EMVCo is creating a combined set of

terminal specifications from the existing four payment brands' specifications and will manage the testing and approval of the contactless kernels according to these specifications. In Phase 2, EMVCo will create a common contactless online-only kernel and, in Phase 3, EMVCo will address the offline market.39 Contactless EMV transactions are designed to function in both offline and online transaction environments and they all leverage the EMV cryptogram security function to validate the authenticity of the card and the transaction. This prevents card cloning and replay fraud. Contactless EMV applications also provide the ability to leverage the EMV velocity counters to limit the number or dollar value of consecutive offline transactions.

5.1.2 Contactless Credit/Debit Payment in the U.S.40 The U.S. led the way with contactless credit and debit payments, with issuance starting in 2005. In the U.S., the payment brands implemented contactless payment transactions to leverage the existing magnetic stripe payments infrastructure and minimize the impact on the merchant and the acquirer network messaging. This approach, called contactless MSD (magnetic stripe data), facilitated straightforward contactless payment implementations by issuers, merchants and payment processors and faster consumer adoption and merchant acceptance. With contactless MSD, the message layout for Track 1 and Track magnetic stripe data remained intact, with one notable difference. The chip on the card allowed for the calculation of a dynamic card verification value based on a card-unique key and a simple application transaction counter. The dynamic card verification value significantly enhanced the security of the transaction and was passed in the message in the same field that was used for the original card verification value. The automatic transaction counter (ATC) was passed in the area reserved on the track layout for issuer discretionary data. Contactless MSD does not support offline authentication or offline authorization. The use of dynamic data in the transaction added security to the payment process by preventing replay attacks (no transaction can be done twice) and card cloning or skimming (the card key never leaves the protection of the smart card memory). In addition, contactless card issuers introduced other changes to the transaction process, including the following:  Many contactless payment cards and devices do not transmit the name of the cardholder, limiting the amount of information that is communicated during the transaction. The cardholder name is part of the existing magnetic stripe data common on most traditional credit cards.  Some contactless payment cards and devices do not include the cardholder's account number, but use an alternate number that is associated with a payment account by the issuer's backend processing system. This alternate number would not be able to be used in other payment transactions (e.g., with a magnetic stripe card or on the Internet). The current generation of contactless cards being issued in the U.S. is based on the EMV standards and utilizes the constructs of a contact EMV card to pass an EMV-compatible cryptogram to the issuer with the authorization request. It is important to note that the merchant acceptance infrastructure primarily supports contactless MSD, which will be upgraded to EMV- compliant contactless terminals as merchants migrate to EMV.

39 EMVCo Common Contactless Terminal Roadmap, EMVCo General Bulletin No. 43, First Edition, November 2009 40 Sources: Smart Card Alliance white papers.

5.1.3 Contactless Benefits

5.1.3.1 Consumer Benefits Industry surveys have shown that consumers value the benefits of contactless payments.41 Consumers appreciate the speed of contactless payment and enjoy the convenience and “coolness” factor offered by the various new contactless payment form factors, such as key fobs and mobile phones. Contactless payments are easy to use—consumers simply place the device in close proximity to the reader. They need not worry about having enough cash or fumbling for cash in a purse or wallet. In addition, new acceptance locations allow consumers to use their contactless devices for purchases that previously required cash—in taxis, at vending machines, and on subways and buses. Another advantage for consumers is that they control the contactless payment device. The device is always in the consumer’s possession, reducing the possibility of leaving it somewhere accidentally and minimizing the potential for fraud. In addition, the transaction uses dynamic data, providing additional protection against fraudulent misuse of contactless data.

5.1.3.2 Merchant Benefits Merchants who accept contactless payments have realized advantages in several areas. First, contactless payments are faster and more convenient for consumers than cash or magnetic stripe card payments. Studies have shown that contactless payments reduce customer time at the POS by 30%–40%.42 A Visa study compared the speed of cash, magnetic stripe "swipe" and contactless transactions at merchants accepting Visa payWave in Columbus, OH. With uniform usage (no signature/PIN) across 465 transactions, the study found that contactless transactions were 4.5 seconds faster than cash and 3 seconds faster than swipe.43 Increased speed and convenience generate greater sales volumes and increase customer spending. Customers spend about 20%–30% more when using contactless payment devices than when they use cash.44 Customers not only spend more: the use of contactless payments also reduces the requirement for and cost of handling cash while also improving operational efficiencies and reducing terminal maintenance costs. Contactless payments present merchants with a tailor-made opportunity for clear differentiation and competitive advantage. The variety of form factors in which contactless payment devices can be available also supports differentiation. Merchants and issuers can collaborate on payment products that blend specific features and packaging (cards, tokens, mobile phones) and target different customer segments that have very particular requirements for the shopping experience. Merchants who accept contactless payments are also prepared for NFC-enabled mobile contactless payments. The contactless POS readers being put in place to accept payment from current branded contactless credit and debit cards are able to accept payment from the same brands without additional modifications when consumers use NFC-enabled mobile phones.

5.1.3.3 Issuer Benefits Contactless credit and debit cards provide issuers with the opportunity to increase cardholder usage in cash-heavy and small-ticket payment environments by making the payment experience

41 Smart Card Alliance, http://www.smartcardalliance.org/articles/2008/09/17/contactless-payment-try-it- youll-like-it 42 Source: Chase 43 Contactless & Mobile Payments, Sandy Thaw, Visa presentation, 2009 Payments Councils Summit, February 24, 2009 44 Source: Chase

faster and easier. Issuers see an increase in transactions in everyday spend categories with merchants who don’t typically accept credit and debit cards. In addition, the consumer's contactless payment card moves to "top of wallet.” Consumers spend more and use the card more frequently, driving incremental transactions and revenue to issuers. Issuers also report better customer retention, as cardholders increase their rewards by increasing daily use of the card for small value purchases. Another benefit is that issuers can differentiate their products with innovative new form factors, tailored to specific consumer preferences (for example, key fobs, mobile devices, or stickers), and provide products and services that take advantage of the functionality available with the new form factors. Issuers also see the potential for multi-application cards that include credit/debit payment and applications such as transit fare payment, campus or corporate ID, and loyalty/rewards programs. Contactless payments technology provides issuers and merchants with a platform for enhanced security and authentication. Contactless cards generate a dynamic cryptogram with every transaction, providing both better information for authorization decisions and tools to reduce fraud resulting from counterfeit cards.

5.1.4 Developments in Contactless Payments Contactless payments have opened up new opportunities for issuers and merchants that take the consumer payment device into new markets and applications.  Contactless technology can be issued in many form factors. Key fobs, mini-cards and stickers can be issued, providing increased convenience to consumers.  Contactless payment transactions create dynamic cryptograms with every transaction. The combination of smart chip technology, which is tamper-resistant and virtually impossible to counterfeit, and the dynamic cryptogram, which makes every transaction unique, addresses the growing fraud problem of counterfeit cards.  The smart chip used in contactless credit and debit cards has the ability to support multiple applications (for example, payment and loyalty, or credit payment and transit payment).  The contactless payments merchant acceptance infrastructure that is being put in place is able to accept transactions both from branded contactless payment and from branded payment applications on Near Field Communication (NFC)-enabled mobile phones. Additional information about NFC can be found in Module 4 and about NFC-enabled mobile payments in Section 6.

6 Mobile Payments Mobile payment is a transfer of funds in return for goods or services in which a mobile device is functionally involved in executing and confirming payment. The payer can be standing at a POS or be interacting with a merchant located somewhere else.45 Consumers can use a mobile device to pay for goods and services such as:  Music, videos, ringtones, online game subscriptions, wallpapers, and other digital goods  Transportation-related items, such as bus, subway, or train fares and parking at meters  Any merchandise in a physical merchant location Section 6.1 reviews the different types of mobile payments, Section 6.2 then focuses specifically on NFC-enabled mobile payments, which leverage the smart card technology-based secure element. 6.1 Characteristics and Types of Mobile Payments As shown in 17, mobile payments are typically differentiated by technology, transaction size, location (remote or proximity), and funding mechanism.

Figure 17. Mobile Payment Differentiators46

45 Innopay, Mobile Payments 2010, http://admin.nacha.org/userfiles/File/The_Internet_Council/Resources/Mobile%20payments%202010%20- %20Innopay.pdf

Location. Remote mobile payments and proximity mobile payments are distinguished by the location of the mobile handset in relation to the merchant’s POS, as well as by payment account information and the payment acceptance device or service. A remote mobile payment is a payment in which the payer does not interact directly with the merchant’s physical POS system (for example, transferring funds through a mobile phone app to a merchant’s PayPal account). A proximity payment is a payment in which the mobile phone interacts in some way with a physical POS device to transfer the consumer’s payment information and perform the transaction. Technology. Mobile payments can use a number of different technologies to perform a transaction. Remote payments typically rely on text messaging (short message service, or SMS), a mobile browser, or a mobile app. Proximity payments rely on either bar codes or a contactless interface to chip-enabled payment technology, such as NFC-enabled mobile phones, Bluetooth “beacons,” contactless stickers, tags, or fobs. Transaction Size. Transaction size affects the choice of mobile payment technology and approach. Mobile payments typically fit into one of two transaction size categories. Micropayments (less than $10-$25) are typical for paying for ring tones, music, parking, transit, coffee, and items in convenience stores. Macropayments (over $25) are typical for all other transactions, such as person-to-person domestic and international remittances, charitable donations, Web site purchases, bill payment and retail POS purchases. Funding Mechanism. Mobile payments can rely on multiple funding mechanisms. Transactions can be included on a telephone bill or funded by a prepaid account associated with the phone (typically used for text-message-based payments). Alternatively, cash can be loaded into a virtual account at an agent location that is then used for payment. Another source of funds is a traditional bank account or credit, debit, or prepaid card, accessed through a virtual wallet (a wallet that is accessed using the mobile phone’s browser or a mobile application). The wallet may provide access to one or more of the above funding sources, which are loaded into the wallet.

6.1.1 P2P Mobile Payment Person-to-person or peer-to-peer (P2P) payment allows individuals to pay one another through a third party. P2P payment services, which are offered by many banks and third parties, can also allow business owners to transfer money to a customer or supplier account (and vice versa) using an e-mail address or mobile phone number. Users can conduct transactions using funds from a bank, credit, debit or prepaid account, or the payment can be funded through the mobile phone bill. PayPal is the leader in the P2P category, with the largest global Internet-based payment network (approximately 165 million active accounts47). PayPal offers a mobile phone app that allows consumers to send and request money using an e-mail address or phone number48 and a service based on SMS. Other examples of P2P mobile payment solutions include the following:  In 2010, Visa announced a new P2P payment service that gives its U.S. customers the ability to receive and send money from their Visa accounts. Visa's service includes a

46 Adapted from Mercator Advisory Group, U.S. Mobile Banking and Mobile Payments: Finding the Seams, Accelerating the Pace, and Smart Card Alliance, Proximity Mobile Payments: Leveraging NFC and the Contactless Financial Payments Infrastructure, September, 2007, http://www.smartcardalliance.org/resources/lib/Proximity_Mobile_Payments_200709.pdf 47 http://www.statista.com/statistics/218493/paypals-total-active-registered-accounts-from-2010/ 48 PayPal web site, http:www.paypal.com

partnership with CashEdge and Fiserv, two P2P financial transaction companies that now have access to VisaNet, the company's payment processing network.49  MasterCard MoneySend uses the mobile browser, SMS, or a mobile app to enable customers to transfer money from person to person using a mobile phone.50 PopMoney51, a service provided by Fiserv, offers a public Web site that allows people to transfer money using e-mail addresses or mobile phone numbers.  One of the most famous examples of P2P is Kenya’s mPesa, the most successful national mobile money deployment in the world. All mobile phone customers using Safaricom as the mobile operator can access mPesa to transfer money. No bank account is required. Usage has expanded from P2P to payment merchants, taxi-drivers etc. The interface is text message based and works on any type of handset. Cash in and cash out is provided through thousands of ubiquitous mPesa agents throughout Kenya.

6.1.2 Remote Mobile Payment Remote mobile payment refers to transactions in which consumers use a smartphone or mobile phone to make purchases without interacting with a physical POS. Most mobile phones deployed over the last five years are equipped with the functionality required to support remote mobile payments, including SMS, secure mobile browser sessions, and mobile apps. Practical use cases for remote mobile payments include making purchases from a Web merchant, paying a merchant who does not have traditional acceptance capabilities for physical goods, paying a merchant for the purchase of digital goods, or sending money to another individual. Remote mobile payments can be implemented using the existing financial payments infrastructure (e.g., for payment at a Web merchant) or a closed loop mobile payments system. One example of the remote mobile payment process is as follows:  The consumer and merchant set up an account with a trusted third party or mobile payment service provider.  When a transaction is initiated, an SMS message is sent to the mobile payment service provider. Authentication can be accomplished using a variety of mechanisms, such as entering a secret password, validating handset hardware information, or verifying other sender personal information.  After the transaction request is received and authenticated, the mobile payment service provider transfers funds from the consumer's account into the merchant’s account and notifies the merchant that the funds have been transferred.  In a closed loop system, the merchant may then move the funds into a standard bank account. Remote mobile payments are ideal for use in markets that require P2P payments and for underbanked consumers and merchants who are not part of the normal POS acquirer payment process, such as flea market vendors and seasonal outside vendors.52

49 Watters, Audrey, Visa Announces P2P Payment Service for U.S. Customers, March 16, 2011, http://www.readwriteweb.com/archives/author/audrey-watters.php 50 https://www.mastercardmoneysend.com/consumer/welcome.shtml 51 https://www.popmoney.com/ 52 Smart Card Alliance, Proximity Mobile Payments: Leveraging NFC and the Contactless Infrastructure, op. cit.

6.1.3 Proximity Mobile Payment Proximity mobile payment refers to a transaction in which a consumer uses a phone to pay for goods or services at a physical POS or with a mobile POS device. Proximity mobile payments can be used at both attended POS locations, such as stores, and unattended locations, such as vending machines. The consumer uses a mobile phone to interact with the merchant’s POS system. Proximity mobile payments can rely on the financial industry’s payment infrastructure or a closed loop payment infrastructure. Merchants can implement proximity mobile payments using NFC technology or other contactless technology and bar codes.

6.1.3.1 NFC-Enabled Mobile Payment One implementation of proximity mobile payment uses NFC technology (also referred to as mobile contactless payment). An NFC-enabled phone is provisioned with a version of a payment application (e.g., American Express ExpressPay, Discover Zip, MasterCard PayPass, Visa payWave) and personalized with a payment account (i.e., credit, debit, prepaid or other closed loop payment application). The phone can then use NFC technology to communicate with a merchant’s contactless payment-capable POS system. To pay, the consumer holds or taps the phone close to the merchant’s reader.53 The consumer’s account information is sent to the contactless POS reader via radio frequency (RF). The payment and settlement processes are the same processes used when a consumer pays with a traditional contactless card. NFC technology can be built in and integrated with new mobile devices or can be added to existing mobile devices using a bridging technology (e.g., microSD card or sticker). Numerous NFC-enabled payment and mobile marketing applications have been piloted and implemented globally. In the United States, Apple Pay and Google Wallet offer the most prominent NFC-based mobile contactless payment services to date.  Apple launched Apple Pay in October 2014, with support in the iPhone 6, iPad Air 2 and iPad mini. Apple Pay is also supported in the Apple Watch (available in April 2015). A straightforward provisioning process allows consumers to add their payment cards to Passbook, with an identity verification process between the consumer and the issuing bank. Apple Pay uses NFC and an embedded secure element to store tokenized payment credentials and requires a fingerprint biometric for the consumer to authorize the transaction. Apple had a very successful launch, lists over 185 issuing banks supporting Apple Pay and can be accepted at merchants supporting contactless payments.54 In June 2015, Apple announced support for store cards and loyalty and rewards cards from select merchants and availability in the U.K. starting in July 2015.55  Google announced Google Wallet in May 2011 with initial availability on Android phones with Sprint. The initial implementation used NFC and an embedded secure element. . Shortly after the release of the new Android KitKat operating system, Google Wallet moved to use host card emulation (HCE) in November 2013 on the first KitKat device to reach the market, the Nexus 5. Since then, Google has fully switched to an HCE implementation and on April 14, 2014, stopped supporting the secure element-based version. With the HCE implementation, payment credentials are stored securely on a remote server; a card token is stored on the mobile phone for use with Google Wallet at an NFC-enabled POS terminal. In February 2015, Google acquired Softcard technology

53 Smart Card Alliance, Proximity Mobile Payments: Leveraging NFC and the Contactless Financial Payments Infrastructure, op. cit. 54 http://www.apple.com/apple-pay/?cid=wwa-us-kwg-features-com 55 “Apple Pay adds loyalty cards and expands to UK,” NFC World, June 8, 2015, http://www.nfcworld.com/2015/06/08/335832/apple-pay-adds-loyalty-cards-and-expands-to- uk/?utm_source=nfcworld-2015-jun-10&utm_medium=newsletter&utm_campaign=nfcworld-2015-jun-10

and Google Wallet will now be offered by the carriers previously supporting Softcard. In March 2015, Google announced the Android Pay API that will allow businesses to add mobile payment as an option to apps and use HCE for NFC mobile payments.56 Android Pay will support tokenization and biometric user authentication. Note: Softcard had been a prominent NFC mobile payment service until Google acquired their technology in 2015. Softcard was the mobile carrier joint venture that included AT&T, Verizon, and T-Mobile. Softcard closed down its applications in March 2015. Samsung has also announced that they will be launching Samsung Pay in 2015. Samsung Pay is reported to be using both NFC and Magnetic Secure Transmission (MST) technology, a secure element, tokenization and biometrics.57

6.1.3.2 Bar Code-Enabled Proximity Mobile Payment Another form of proximity mobile payment is based on the use of bar codes. A two-dimensional (2D) bar code is displayed on a smartphone screen and read by an optical scanner at a retail POS, or the smartphone’s camera is used as an optical scanner to read a bar code displayed on a POS terminal.58 Starbucks has rolled out mobile payment using 2D bar code technology to its nearly 6,800 company-owned stores in the United States. Consumers can download the Starbucks Card mobile app to an iPhone or iPod Touch, a variety of BlackBerry models, and select models of Android phones. The app displays a bar code that the customer uses as a Starbucks Card to make purchases. When the bar code is scanned at the POS, Starbucks deducts the amount of the purchase from the customer’s Starbucks Card account. The app also lets a cardholder track the card balance, add to it with a major credit card, check the status of rewards points, and locate nearby Starbucks outlets.59

6.2 NFC-Enabled Mobile Payments This section provides a more detailed review of one specific mobile payment approach – NFC- enabled mobile payments – outlining the NFC ecosystem players and roles. A more detailed description of NFC technology and applications can be found in Module 1 and Module 4. NFC technology is a standards-based wireless communication technology that allows data to be exchanged between devices located a few centimeters apart. The technology can be used for a wide variety of mobile applications, including:  Making payments with a wave or a touch of a device anywhere contactless POS readers have been deployed  Reading information and picking up special offers, coupons, and discounts from posters or billboards on which an RF tag has been embedded (for example, in smart posters and billboards)  Securely storing tickets for transportation, parking access, or events and enabling fast transactions at the point of entry/exit

56 “Google Will Launch Android Pay at I/O Developer Conference,” PYMNTS.com, May 26, 2015, http://www.pymnts.com/news/2015/google-will-launch-android-pay-at-io-developer- conference/#.VX9yo_lVhBc. 57 “Samsung Announces Samsung Pay, a Groundbreaking Mobile Payment Service,” Samsung press release, March 1, 2015. 58 National Retail Federation, Mobile Retailing Blueprint: A Comprehensive Guide for Navigating the Mobile Landscape, January 2011, http://www.nrf.com/modules.php?name=Pages&op=viewlive&sp_id=1268 59 Balaban, Dan, Starbucks Rolls Out Bar-Code Mobile Payment Nationwide, NFC Times, Jan. 19, 2011, http://www.nfctimes.com/news/starbucks-roll-out-bar-code-mobile-payment-nationwide

 Securely storing information that allows secure building access NFC-enabled devices are governed by standards in ISO/IEC (ISO/IEC 18092), ETSI (ETSI TS 102 10 V1.1.1 (2003-03)) and ECMA International (ECMA-340), and by specifications published by the NFC Forum. ISO/IEC 18092 allows for backward compatibility with existing contactless devices by supporting ISO/IEC 14443 (the standard used by payment network-branded contactless payment cards and devices), and the Japanese Industrial Standard (JIS) X 6319-4 (also known as FeliCa) contactless interface protocols. An NFC-enabled device can operate in reader/writer, peer-to-peer, or card emulation mode. For mobile contactless payments, the NFC-enabled mobile device operates in card emulation mode and appears to an external reader to be a traditional contactless smart card. Payment information is stored in the mobile phone in a secure element, which is a smart card chip that protects stored data and enables secure transactions, or in the cloud and uses host card emulation to deliver the payment account information. Contactless payments and ticketing using NFC devices can be enabled without changing the existing acceptance infrastructure, as long as there is a contactless reader at the POS. The next two sections describe the two card emulation approaches being used for NFC-enabled mobile payments: card emulation with a secure element and host card emulation. (See CSCIP Module 4: Smart Card Usage Models – Mobile and NFC for details on technical implementation of secure element and host card emulation approaches.)

6.2.1 Secure Element-Based NFC Mobile Payments

6.2.1.1 The NFC Mobile Payments Ecosystem Using a Secure Element Deploying NFC mobile payment applications using a secure element requires an ecosystem in which stakeholders cooperate to deliver different functions and capabilities. The NFC mobile payments ecosystem includes the following key stakeholders:  Secure element (SE) providers and issuers  Mobile network operators  Handset manufacturers  Operating system providers  Mobile wallet developers  Trusted service managers (TSM): secure element issuer (SEI) TSMs and service provider (SP) TSMs  Application service providers: bank card issuers, transit agencies, merchants, other NFC application providers (e.g., coupons)  Consumers  NFC application acceptors: merchants, transit agencies  Payments processors: bank card acquirers, payment brands, closed payments system processors

6.2.1.1.1 Secure Element Providers and Issuers The heart of a secure NFC application is the SE. The SE is a secure microprocessor (smart card chip) that includes a cryptographic processor to facilitate transaction authentication and security and provide secure memory for storing payment applications (e.g., American Express ExpressPay, Discover Zip, MasterCard PayPass, Visa payWave, other closed loop payment application). SEs can also support other types of secure transactions, such as transit payment

and ticketing, building access, or secure identification. The Java Card operating system with GlobalPlatform support is the de facto industry standard for SE implementations. The SE provider provides an SE in the form factor required by the SE issuer. The SE issuer is then responsible for issuing and maintaining the secure element. Depending on how the SE is implemented for mobile payments, the issuer could be the MNO, a bank card issuer, or another stakeholder; a variety of stakeholder relationships are possible, depending on the SE form factor. A mobile handset can implement an SE in one or more of the following ways:  Embedded SE  UICC removable SE  MicroSD removable SE Embedded SE. One option for implementing an NFC-payment-capable SE is to embed it in the phone when the phone is manufactured. This implementation does not provide the consumer with the option of moving the SE from one phone to a replacement phone. However, it allows the phone’s manufacturer and mobile operating system providers to design, certify, and implement basic NFC payment transaction applications for a particular phone. UICC removable SE. A second option is to include an NFC-enabled SE in a removable UICC or SIM card that supports the Single Wire Protocol (SWP). SIM cards have been used in mobile phones for years. Although the SIM slot on the phone is not designed to accommodate frequent changes and therefore is typically not accessible from the external casing of the phone, some phones include accessible SIM slots. Consumers who buy a new phone for use with the same MNO can insert the SIM card from their old phone into their new phone, use the phone on the MNO’s network, and port their contact information and phone number to the new handset. MicroSD removable SE. The microSD is an SE form factor that can enable mobile contactless payment on phones that do not have built-in NFC capabilities. Many phones on the market already support microSD cards. The microSD can contain a payment application, a cryptographic coprocessor, the NFC controller and antenna, and even the user interface to a wallet. Mobile phones lacking embedded NFC capability can therefore be enabled for mobile contactless payment by inserting a microSD card. It is important to note that microSD cards come with different configurations and interfaces that affect performance and often require hardware and software support from the handset. Industry expectation is that future handsets will include an embedded SE or support a UICC removable SE. One reason that more NFC-enabled phones are not currently available is that handset manufacturers have been slow to adopt the SWP, which is required for a UICC to communicate with the phone antenna and NFC modem. Several solutions are available that can bridge the gap and equip selected phones with SEs. Smart contactless stickers can be attached to mobile phones; such stickers act only as contactless payment cards, with no added value provided by the phone. MicroSD cards with smart card components can also be added to mobile phones, enabling phones with a suitable card slot to support NFC. Other accessories (such as iCarte™) are available that can provide iPhones™ with NFC capability. A variety of stakeholder relationships are possible, depending on how the SE is implemented. Section 6.2.1.2 provides examples of the possible relationships and interactions among stakeholders for the three SE approaches.

6.2.1.1.2 Mobile Network Operator The MNO maintains the mobile communication infrastructure and provisions wireless settings to the phones provided to consumers. The MNO also determines both the required handset features and functions and the service options to be provided with mobile phones sold by the operator. The MNO ensures OTA connectivity between the consumer and the NFC application SP.

6.2.1.1.3 Handset Manufacturer The handset manufacturer defines which mobile phone models will be NFC-enabled, based on the MNO’s requirements and the demand projected in the market. Handset manufacturers may also have a stake in the embedded SE model (as opposed to other SE approaches), potentially introducing additional business models.

6.2.1.1.4 Operating System Provider An operating system (OS) provider maintains the core OS used by various handsets, including version upgrades, and provides application programming interfaces so that application developers can provide compatible applications. The OS provider may also provide a wallet application and other value-added applications.

6.2.1.1.5 Mobile Wallet Developer A mobile wallet developer provides the consumer with an interface on the mobile phone to manage multiple NFC payment applications, including transit applications. To facilitate consumer demand for multiple payment options, a wallet developer can provide the wallet directly, as part of an application provider’s NFC payment solution, as an application provided by the MNO, or through another vendor or SP.

6.2.1.1.6 Trusted Service Manager The TSM is a trusted third party who provides over-the-air (OTA) services to the NFC payment application service provider and the owner of the SE. The TSM handles provisioning and management processes so that application service providers do not need to deal with multiple MNOs, phone models, and operating systems, and MNOs do not need to deal with multiple providers. The TSM role can be played by many different entities, including the MNO, an application service provider, a personalization bureau, a payments processor, or some other third-party SP. Multiple TSMs may be involved in provisioning a payment application. The primary role of the TSM in the NFC ecosystem is to facilitate management of the NFC payment application that is stored in the secure element on the consumer’s phone. Functions provided by the TSM can include OTA activation or provisioning of the NFC secure element payment application, life-cycle management of the application, and bridging services for transferring the application to a new phone. A core piece of the OTA provisioning process includes preparing the data and accessing the appropriate security keys required to provision the NFC secure element payment application initially and then to update it once it is provisioned. The TSM’s role is central to provisioning NFC services. The TSM acts as the secure connection point between SPs, such as banks, transit authorities, and merchants, and the SE owners, such as MNOs.

6.2.1.1.7 Application Service Providers Application SPs provide the applications and services required to deliver applications to NFC- enabled mobile phones. The NFC ecosystem can include numerous application SPs: bank card issuers, transit agencies, and merchants, among others. Application SPs work through TSMs to deliver NFC functionality to consumers. They may also work with existing SPs for service delivery. (For example, bank card issuers may work with their personalization bureaus to create personalization data, set application security keys, and pass data to a TSM who then provisions the data into a consumer’s NFC-capable phone.) Application service providers may be any of the following entities:  Bank card issuers, who provide payment applications and payment accounts to consumers and accept transactions from the bank payments infrastructure. In the

standard card payment system model, the bank (issuer) holds the funding account for a consumer’s payment card and is responsible for provisioning credit and debit cards to the bank’s customers. In the emerging NFC payment system model, the bank continues to hold the funding account but works with other parties to provision the payment application to NFC-enabled mobile phones. In most cases, issuers will deploy physical “companion cards” for use at locations where NFC mobile contactless payment is not accepted. The bank card issuers’ host systems will need to support mobile contactless transactions. Banks may support their own application provisioning or work with existing partners (e.g., a personalization bureau).  Transit agencies, who issue closed transit ticketing, payment or other NFC applications to consumers and accept transactions within the transit environment.  Merchants, who issue merchant-specific payment or other applications and accept transactions within the retail environment. Merchants can accept NFC payment transactions and also issue NFC payment applications. To accept NFC payment transactions, merchants need NFC-enabled contactless POS terminals that are certified to work with each payment brand’s application. Merchants can also choose to implement closed-loop NFC payment applications (such as gift cards or a merchant-specific payment card) or other value-added applications (e.g., coupons, loyalty cards).  Other SPs, who offer value-added applications such as coupons, loyalty programs, merchant promotions and offers, and location-based services.

6.2.1.1.8 Consumer In the context of the NFC ecosystem, the consumer is a customer of the NFC application provider. How the consumer becomes aware of NFC payment options can determine how the NFC payment capability is loaded to the consumer’s handset.

6.2.1.1.9 NFC Application Acceptors Both merchants and transit agencies can be viewed as NFC application “acceptors”—participants in the ecosystem who have enabled their acceptance infrastructure to interact with a consumer’s NFC-enabled mobile phone to complete a transaction. To accept NFC payment transactions, merchants need NFC-enabled contactless POS terminals that are certified to process each payment brand’s NFC payment application. Retailers can also choose to implement closed-loop NFC payment applications (such as gift cards or a retailer-specific payment card) or other value- added applications (such as coupons or loyalty programs).

6.2.1.1.10 Payments Processors Transaction processing stakeholders are determined by the type of NFC payment application. For open bank card payments, the merchant or transit agency routes the transaction to the merchant acquirer for authorization, clearing, and settlement through the payment networks to the issuers. To support NFC payment transactions, acquirer terminals at merchant customer locations must support NFC/contactless transactions. To support NFC payment transactions, acquirers and payment networks must support contactless messaging and authentication functions. For closed payment systems, the merchant or transit agency routes the transaction to the appropriate back-end system for processing and settlement.

6.2.1.2 Mobile Contactless Payments Stakeholder Relationships and the Secure Element Using a mobile phone as a carrier for an NFC payment application creates the potential for a wide variety of relationships between the infrastructure stakeholders. The secure element (SE) chosen and the entity responsible for life-cycle management have a direct effect on the relationships among the NFC stakeholders and the approach for NFC payment application provisioning. For this reason, it is valuable to examine the relationships of the stakeholders in the NFC ecosystem within the context of the SE type, the SE and payment application distribution route, and the payment application activation options. Figure 18, Figure 19 and Figure 20 illustrate three possible paths and relationships for implementing mobile contactless payments with branded payment applications (i.e., American Express, Discover, MasterCard Worldwide and Visa payment applications).

6.2.1.2.1 UICC-Centric Model Figure 18 illustrates NFC payment application enablement and provisioning possibilities and stakeholder relationships when the SE is in the UICC.

Figure 18. UICC-Centric Model Figure 18 illustrates the following key points for a UICC-centric implementation:  The MNO typically owns and controls the secure element and distribution of it to consumers. Accordingly, a consumer is only able to obtain NFC payment capability by purchasing a new phone from the MNO or obtaining a new UICC from the MNO. Therefore, only one distribution route is available.

 Multiple entities can provide the payment and wallet application activation, personalization, and life-cycle management functions that are typically associated with a TSM. The MNO, a bank, or a private label card merchant issuer can implement TSM functionality or outsource this functionality to a third party TSM, as illustrated by the box in the diagram labeled “Independent TSM.”  This model permits MNOs to offer their own payment applications, assuming that the acquiring networks will support the application. The dotted red line shows this payment transaction processing path.

6.2.1.2.2 Embedded SE Model Figure 19 illustrates NFC payment application enablement and provisioning possibilities and stakeholder relationships when the SE is integrated into the mobile phone during the manufacturing process.

Figure 19. Embedded SE Model Figure 19 illustrates the following key points for an implementation in which the SE is embedded in the phone:  The MNO typically owns and controls the SE and distribution of it to consumers.

 Embedding an SE as a standard hardware feature within certain phones enables payment application providers to align with mobile OS providers to bring new applications to market (for example, Google Wallet).  Multiple entities can provide the payment and wallet application activation, personalization, and life-cycle management functions that are typically associated with a TSM. The MNO, a bank, a private label card merchant issuer, or a third-party payment application or wallet provider can provide TSM functionality or outsource this functionality to a third party TSM, as illustrated by the box in the diagram labeled “Independent TSM.” Any payment application or wallet provider can use the services of the independent TSM.  This model permits MNOs to offer their own payment applications, assuming that the acquiring networks support the application. The dotted red line shows this payment transaction processing path.

6.2.1.2.3 MicroSD-Centric Model The microSD-centric model is the most challenging to illustrate, because distribution can be handled in so many ways. In the UICC and the embedded SE models, distribution of the SE is tied tightly to distribution of the phone itself. However, in the microSD-centric model, many different entities can distribute the SE because the microSD plays a dual role. The microSD can include the SE, the NFC controller, the antenna that enable communication between the NFC- enabled phone and a contactless POS terminal, and the wallet. With this model, consumers don’t need to change phones to have NFC functionality; they simply insert an NFC-enabled microSD card into their existing phone. Figure 20 shows three potential distribution paths:  Potential paths when the bank owns and distributes the microSD, labeled “1”  Potential paths when the merchant issuer owns and distributes the microSD, labeled “2”  Potential paths when the MNO owns and distributes the microSD, labeled “3”

Figure 20. MicroSD-Centric Model Figure 20 illustrates the following key points for the microSD-centric model:  Ownership of the SE is less restricted than in the other models. A bank issuer, a merchant issuer, or the MNO can own and distribute the microSD.  Use of a microSD opens up many more distribution paths. Banks or merchant issuers can use their current personalization bureaus to mail microSDs, either with a consumer’s standard plastic credit card or alone. An MNO has the same options; to reduce the complexity of the diagram, however, Figure 20 shows the MNO distributing the microSD directly to the consumer.  As with the other SE options, many different entities can provide the TSM functions required to activate, personalize, and manage the life cycle of a wallet or payment application stored on the microSD.

6.2.1.3 NFC-Enabled Mobile Payments Security Approaches Figure 21 illustrates the security mechanisms that protect the data and processes used in NFC mobile contactless payments.60 Security for payment applications and account information must be in place when being provisioned, while being stored on the mobile device, when being used by consumers during a payment transaction, and while managing the device, application and account life cycle.

60 Canadian implementations may be different.

Figure 21. NFC Mobile Contactless Payments Security Mechanisms

6.2.1.3.1 Delivering Financial Data Securely to the Mobile Device The transmission of payment, personalization, and life cycle management information from the issuer to the TSM is secured by standard Internet technologies, such as secure sockets layer (SSL) or virtual private networks (VPNs). The data is protected by cryptography throughout the process. GlobalPlatform’s secure channel protocol provides for transmission of sensitive account data between the TSM and the SE in the mobile device. Account data is further kept secure from OTA sniffing by encryption provided by the MNO. The TSM has a critical role in managing the security of the process and keeping the cryptographic keys secure through the use of both physical and logical security measures.

6.2.1.3.2 Securing the Stored Payment Application and Account Information Within the mobile phone, both the payment application and consumer account information must be protected and different NFC applications must be able to work securely and independently of each other. This section reviews how data is securely stored in the mobile handset and how data and applications are securely accessed and used.

6.2.1.3.2.1 Secure Element Storage Applications and data are stored in the secure element. (See Section 6.2.1.1.1 for a description of different secure element implementations.) The secure element (secure memory and execution environment) is a dynamic environment in which application code and application data can be securely stored and administered and in which secure execution of applications occur. The element resides in highly secure crypto chips61 (a smart card chip). The element provides

61 A crypto chip is a powerful, high-speed, programmable cryptographic engine for operating private and public key-based encryption systems.

delimited memory for each application and functions that encrypt, decrypt, and sign the data packet. The secure element present in mobile devices is GlobalPlatform compliant to provide better interoperability. By using the smart card technology that is inherent in the SE, all communications with the application to update or change operational parameters can be authenticated and the smart card chip provides built-in tamper resistance and security features that recognize hostile attacks and take appropriate protective measures, such as blocking the application.

6.2.1.3.2.2 Security Domains and Hierarchy The GlobalPlatform specification (Version 2.2)62 defines multiple security domains that use authorized and delegated management to allow an application to be loaded into the secure element. Mobile contactless payment would typically establish the hierarchy for security domains shown in Figure 22.

Figure 22. Architecture of the Secure Element, Security Domains, and Applications Any GlobalPlatform-compliant secure element comes with one issuer security domain (ISD) (for the SE issuer in this case) and the option for multiple supplemental security domains (SSDs). As shown in Figure 22, the SSDs can be TSM security domains or domains belonging to service providers (such as credit card, ticket, prepaid/loyalty card, or transit card issuers). In addition, each secure element can have only one controlling authority security domain (CASD). This security domain architecture enables the service provider and trusted service manager to perform key management and application verification during load and installation processes. The ISD is the portion of the secure element in which the keys are stored for the following:  OTA provisioning  Card content management  Security domain management

62 http://www.globalplatform.org/specificationscard.asp

The ISD has privileges for global management, authorized management, and security domain management for the secure element. The ISD must be created during manufacturing and the key for card content management securely transferred from the manufacturer to the SE issuer. The ISD must authorize the creation of any SSDs. Only the ISD has the privileges to create an SSD and assign authorized or delegated management privileges. An SSD can have its own card manager key for loading applications. The ISD can assign different sets of privileges (based, for example, on different business relationships) to the SSD designated as the TSM security domain and the SSD designated as the service provider security domain.

6.2.1.3.2.3 API to the Secure Element An API between applications on the phone and the secure element is needed to enable over-the- air and local card management services. For phones that implement Java, two Java interfaces to the secure element are defined: JSR 177, to access SIM cards, and JSR 257, to access the NFC chip. For phones that do not support Java, the handset and/or operating system vendor need to provide equivalent APIs to access the secure element and NFC chip. A good practice is to require all phone applications that need to communicate to the secure element to be authenticated by a trusted entity (e.g., the carrier or handset vendor). The phone’s operating system will then prevent access to the secure element APIs by any non-trusted applications.

6.2.1.3.3 Enabling Secure Payment Transactions at the POS For a mobile contactless payment transaction to be possible, the NFC-equipped mobile device must be loaded with a payment application and account information and the merchant terminal must be configured to accept contactless transactions. The payment transaction is then performed much like a standard contactless credit or debit card transaction. The mobile device is presented to the terminal at the point at which a contactless payment card would be presented. The terminal initiates communication with the mobile handset. The terminal does not constantly scan the nearby (two to four-inch range) area for an active mobile handset; rather, it only attempts to locate the mobile handset or contactless payment card when it prompts the user to present the device. Once the device is located, communication between the terminal and the handset takes place within 500 ms. When a transaction ends, a final command is sent to the mobile device by the terminal. However, the terminal does not consider the communication to be complete until the mobile device is moved out of the field of communication. That is, another transaction cannot take place until the mobile device that executed the previous transaction is moved completely away from the contactless reader field and the cashier initiates a new transaction. Communication between the application on the secure element and the contactless reader (via the NFC chip) is based on two standards: ISO/IEC 7816 and ISO/IEC 14443. ISO/IEC 14443 helps the reader and NFC chip establish the device parameters for NFC communication.

6.2.1.3.3.1 Consumer Experience From the perspective of the consumer, an NFC-enabled mobile phone behaves exactly like a contactless payment card during a transaction. The amount of interaction between the consumer and the phone depends largely on the implementation of the payment application on the phone, which is defined by the issuer or the payment brand. There is no specific requirement for consumer interaction, just as there is no requirement for a cardholder to interact with a contactless card during a transaction. The consumer only interacts with the terminal.

The payment application that is loaded to the mobile device may be designed such that the consumer must enter a passcode or present a fingerprint to the mobile device to initiate or respond to the terminal's transaction initiation or to validate the transaction. Passcode entry or biometric authentication is meant to provide an additional level of security for the transaction. In fact, the U.S. Apple Pay implementation uses a fingerprint as the transaction authentication. If the consumer has multiple payment applications on the phone, each could feasibly have different user requirements for conducting a transaction. The handset firmware can also determine accessibility to the payment application using the NFC modem. The configuration options available for the NFC modem in a handset vary by handset manufacturer. For example, one handset could have the following configuration options:  Always allow access to the application (card is always available)  Allow access to the application only after user confirmation  Only allow access to the application upon input of the correct passcode (set by the user) When more than one payment application is installed on a single handset, a mobile wallet can be loaded on the phone to manage the multiple application interfaces. The wallet enables the consumer to select a preferred payment or issuer brand for each transaction, analogous to a consumer opening a wallet or purse and selecting the card to use for a transaction. A wallet may use an optional personal identification number (PIN) or passcode to authorize access to the wallet. A mobile wallet can also enable the consumer to designate one brand as a default payment brand. For example, if a person primarily uses a specific credit or debit card, that application can be set as the default payment brand. To use a different payment account in a retail outlet, the user would need to select a different payment brand.

6.2.1.3.3.2 Payment Transaction Security Payment transactions would use the security that is specified for the type of payment application being used (credit, debit, prepaid or closed loop payment system). Contactless bank card payment transactions invoke additional layers of security during transaction processing. In the case of a mobile contactless payment transaction, the first layer of security is provided by the secure element itself, which protects the payment application by storing it in restricted access memory. The mobile contactless payment application generates a dynamic cryptogram that is integrated into the transaction messaging/communication process with the terminal; the cryptogram is unique for each transaction. The terminal and the merchant system perform risk management checks; the host system then completes an authorization function, which checks the authorization limit available and card validity, among other things. Tokenization is also being used in mobile NFC contactless payments (e.g., Apple Pay), replacing the account number with an alternate number that is stored on the mobile device.

6.2.1.4 Mobile Device Lifecycle Considerations The mobile phone industry is highly competitive and driven as much by fashion as by features and functionality. People often see a mobile phone as a fashion statement and change their phone style based on trends in the fashion industry. The twin influences of fashion and functionality have resulted in a continuing compression of the handset life span and pressure on the handset manufacturers to shorten the handset development and release cycle. In addition, for all practical purposes, there is no connection between the MNO’s service contract and the phone used to fulfill the contract. It is common for consumers to change phones one or more times over the life of a service contract. When they do, the old phone ends up in a scrap drawer or the garbage.

6.2.1.4.1 Mobile NFC Activation The mobile payment application can be activated at the same time as the account-specific information is loaded onto the secure element, independent of the secure element form factor. Inactive mobile payment applications can be preloaded on a handset and delivered to consumers, who have the choice of whether and when to activate them. In the mobile NFC market, the payment application will be loaded in the secure element. Once the handset manufacturer has released a mobile handset, an MNO purchases and inventories the phone. If the handset has an embedded secure element for the payment application, the application may already be on the phone but will need personalization and activation. It is also possible that the payment application could be loaded to the phone following release. If the handsets are designed to be equipped with a UICC or microSD card as the secure element, the handset will receive the payment application when the UICC or microSD card is inserted into it. The MNO or the handset vendor acting on behalf of the MNO (i.e., a retailer) adds the secure element when the phone is set up for the consumer. It is also possible that the retailer will have these secure elements prepackaged in the handset and inventory. Since the payment application is not initially linked to the consumer, the consumer will be given instructions on how to personalize and activate their payment application. It is possible that the activation and personalization of the payment application can be performed at the retail outlet where the phone is sold.

6.2.1.4.2 Changing NFC Mobile Phones The process of changing NFC mobile phones has different implications for managing the security of consumer data and payment applications resident on the secure element based on the type of secure element. Consumers will need to be educated to ensure that their personalized data and payment applications are securely transferred from one mobile NFC phone to a new phone. As noted earlier, in the U.S., consumers have the habit of discarding “old” mobile phones when taking advantage of new handset functionality or fashion features. For 3G networks, the UICC links the user’s service contract to the phone and can be the location of the secure element for mobile payment applications. Accordingly, the subscriber’s identity and mobile payment applications can move with the UICC as it is transferred from the old phone to the new NFC phone For handsets with microSD cards or UICC cards, when a consumer buys a new phone, the consumer will need to remove the UICC or microSD card from the old phone and place it in the new phone. Once the card is removed, the old phone is no longer connected to the person in any way. All personalized data and applications have been moved to the new phone. Use of a removable UICC or microSD card allows the consumer to control the phone that includes the payment application. If not switching issuing banks or mobile network providers, there is no need to contact the bank or the MNO when changing phones other than to confirm that the new handset is payment enabled. On the other hand, if the secure element is integrated into the phone, changing phones will require that the payment application on the phone be de-activated, if not removed. This may be possible through a user interface on the phone, or via a set of instructions for the consumer to follow.

6.2.1.4.3 Lost or Stolen Phones If a phone used for mobile contactless payments is lost or stolen, the security of the payment application is determined by the payment application’s implementation. In other words, if the handset is configured to require passcode activation of the payment application each time, the lost or stolen phone represents a minimal financial risk. The consumer would need to report the

lost device to their bank, and the bank would need to send a payment application deactivation or block request through the TSM. However, the primary deactivation security would rely upon the host system as it does today with credit cards. If a card is lost or stolen, the consumer must report that fact to the issuer, who closes the account on the host system. When the account is closed on the host system, the card or phone will not be able to receive an authorization because the host system would also have been programmed to reject any new transaction requests. The only risk exposure would be linked to offline transaction limits that may have been configured for that consumer.

6.2.2 Host Card Emulation-Based NFC-Enabled Mobile Payments63 To date, implementations of NFC-enabled mobile payments have relied on the secure element (SE) in the mobile phone to facilitate transaction authentication and security, and to provide secure memory to store payment applications and account information. Provisioning the payment application and payment account to the mobile phone is done through an infrastructure that includes the account issuer, one or more TSMs, and MNO. An alternate approach, pioneered by Google, uses host card emulation (HCE). This section reviews considerations for using HCE for payments. For details on the technical implementation of HCE vs. secure element technology, see CSCIP/P Module 4: Smart Card Usage Models – Mobile and NFC.

6.2.2.1 Current Support for HCE-Enabled Payments This section discusses a few commercial implementations of HCE-enabled payments have been announced recently.  Google Wallet in the United States  Tim Hortons in Canada  MasterCard and Visa support for payment apps using HCE that comply with their contactless payment specifications  BBVA in Spain

6.2.2.1.1 Google Wallet Google Wallet for NFC payments was initially implemented using an SE-based model. Shortly after the release of the new Android KitKat OS, Google Wallet appeared using an HCE implementation in November 2013 on the first KitKat device to reach the market, the Nexus 5. Since then, Google has switched to an HCE implementation and on April 14, 2014, stopped supporting the SE-based version.64 Google Wallet's tap-and-pay feature is available at U.S. retail locations supporting contactless payments and requires an NFC-enabled device running Android 4.4 (KitKat) or higher on any carrier network.65 Google has confirmed its move to HCE: “Host card emulation allows Android applications to communicate directly over NFC on supported devices with Android 4.4 KitKat. When you tap your phone to pay, HCE enables Google Wallet to pass transaction information to the point-of-

63 The content in this section is from the Smart Card Alliance Mobile and NFC Council white paper, “Host Card Emulation (HCE) 101, published in August 2014. 64 Sarah Clark, “Google Wallet ends support for physical secure elements,” NFC World+, Mar. 17, 2014, http://www.nfcworld.com/2014/03/17/328326/google-wallet-ends-support-physical-secure-elements/. 65 https://support.google.com/wallet/answer/1347934?hl=en.

sale terminal to complete your transaction.”66 Devices that are running older operating systems may no longer support Google Wallet’s tap-and-pay feature. The user experience is similar in both the SE and HCE implementations. Google also states that payment credentials are not shared with merchants and are stored securely on a remote server.67 Because Google stores payment account information in the cloud and actual card numbers are not shared with retailers, this approach could be viewed as a form of tokenization, as opposed to storing actual credentials on the mobile device, minimizing the chance of compromising credentials at a merchant location. (Additional information on tokenization can be found in Section 6.2.2.2.2.) This service also provides a purchase history (merchant details, transaction time and amount, optional geolocation information) that can be reviewed using the wallet app.

6.2.2.1.2 Tim Hortons Tim Hortons68 mobile payments service enables customers to tap to pay with a BlackBerry 10 smartphone, using a mobile version of the chain’s closed-loop Tim Card (similar to a Starbucks card). Because Apple devices do not natively support NFC, QR codes are used to accommodate customers using iOS devices (running iOS version 6.0 and higher).

6.2.2.1.3 Visa and MasterCard In February 2014, Visa announced it is “offering clients new options to securely deploy mobile payment programs, including for the first time an option to host Visa payWave-enabled accounts in a secure, virtual cloud,” leveraging the HCE architecture. As part of this support, Visa is introducing new standards, tools, and guidelines for payWave HCE support.69 The initial Visa payWave standard for cloud-based deployment is available. MasterCard also announced that it is publishing specifications that leverage HCE for secure NFC payment transactions. MasterCard’s press release indicated that HCE pilot projects are already underway with Capital One in the U.S. and Banco Sabadell in Europe.70 The MasterCard and Visa implementations use EMV-compliant messaging to ensure compatibility with installed EMV contactless POS terminals.

6.2.2.1.4 BBVA BBVA announced that they have commercially launched a host card emulation-based mobile contactless payments service in Spain taking advantage of Visa’s support for HCE.71 BBVA has updated its Android wallet app for Spanish customers and is planning to introduce the technology in the U.S., Mexico and Chile.

6.2.2.2 Credential Storage and Security Using HCE HCE does not rely on an SE for credential storage. To enable HCE, the payment credentials can be stored on the device as a static image, or they can be dynamically updated by a secure server

66 Google Wallet FAQ, http://www.google.com/wallet/faq.html#tab=faq-security. 67 Google Wallet FAQ, http://www.google.com/wallet/faq.html#tab=faq-security. 68 “Tim Hortons launches NFC payments service using Host Card Emulation,” NFC World, December 13, 2013, http://www.nfcworld.com/2013/12/13/327339/tim-hortons-launches-nfc-payments-service-using- host-card-emulation/. 69 “Visa to Enable Secure, Cloud-Based Mobile Payments,” Visa press release, February 19, 2014, http://investor.visa.com/news/news-details/2014/Visa-to-Enable-Secure-Cloud-Based-Mobile- Payments/default.aspx. 70 “MasterCard to Use Host Card Emulation (HCE) for NFC-Based Mobile Payments,” MasterCard press release, Feb. 19, 2014, http://newsroom.mastercard.com/press-releases/mastercard-to-use-host-card- emulation-hce-for-nfc-based-mobile-payments/. 71 “BBVA introduces HCE-based mobile payments,” Finextra, June 30, 2014, http://www.finextra.com/news/fullstory.aspx?NewsItemID=26217.

in the cloud, based on the business rules associated with the payment application. However, serious security issues are associated with storing static data on the device. There are at least two approaches to protecting sensitive payment card credentials stored on a cloud-based system during transactions: transactions without tokenization72 and transactions with tokenization. In both approaches, all of the card information is stored securely in the cloud. The cloud-based server can be hosted by a wallet provider, a retailer, or a bank (or a processor on behalf of a bank or a retailer).

6.2.2.2.1 Cloud Storage without Tokenization An HCE-enabled NFC payment transaction without tokenization proceeds as follows: 5. The customer registers and acquires the card credentials either through a mobile app or using the provider’s secure Web-based service (such as a bank’s Internet banking site). 6. At time of payment, the customer is authenticated by the cloud (using the credentials entered on the mobile app). The customer then selects a card to use for payment from the mobile wallet app. 7. The payment credentials are sent to the customer’s mobile device to initiate the transaction. The device transmits the payment credentials to the merchant using NFC. This solution is not considered secure. The payment credentials can be exposed by malware resident on the device. This approach is unlikely to find favor with the global payment brands.

6.2.2.2.2 Cloud Storage with Tokenization An HCE-enabled NFC payment transaction with tokenization would proceed as follows: 1. The issuer offering the mobile payment service guides the customer through an enrollment/registration process that incorporates strong authentication methods and the consumer downloads the mobile payment app. 2. The customer’s mobile app is provisioned with payment tokens, which may have limited validity depending on the business rules defined by the issuer. For example, the token may be:  Valid only for transactions not exceeding a certain amount threshold  Limited to a single use (after which a new token must be provisioned to the mobile device)  Valid only for a limited time  Valid only for mobile contactless payment transactions  Valid only at a given merchant or merchants Provisioning of the payment tokens is typically carried out in advance of any payment transactions to avoid increasing transaction latency times. Moreover, provisioning the payment tokens requires the mobile device to have data connectivity, which may not be available to the customer when the payment transaction is initiated. 3. At time of payment, the customer’s mobile payment app provides the tokenized payment credentials to the merchant’s POS using NFC. The customer may be prompted to enter a PIN specific to the use of the mobile payment app. 4. The merchant routes the transaction to the acquirer, and the transaction is ultimately received by the issuer (over the payment network) for authorization. The issuer (or an

72 Tokenization in payments replaces the primary account number (PAN) with a surrogate value that is used in transactions in place of the PAN.

entity acting as the token vault on behalf of the issuer) authorizes the transaction after verifying the token and identifying the associated payment credentials. Note that this solution would also need to consider how to securely provision the payment token to the device. This solution does not reduce the risk of credential exposure due to malware on the device, but reduces the impact of eventual exposure by replacing the static payment credential with a token of much reduced scope. Malware risk is increased if the device is exploited, jailbroken or rooted.73 To enhance security, implementations may use white box cryptography and software tamper proofing to replace SE functionality by software and be supplemented by techniques such as device fingerprinting and risk-scoring mobile payment transactions prior to authorization.

6.2.2.3 Routing Mechanism for Multiple Payment Implementations in a Mobile Device HCE has the potential to increase use of NFC. However, some issuers may still prefer the SE- based payment approach. For this reason, while HCE simplifies NFC implementation by eliminating the requirement for an SE, smartphones supporting HCE will still have to support SE- based transactions. This will require the smartphone to be able to select the appropriate application. When a customer chooses a payment app that stores credentials inside the SE, the NFC controller routes the transaction to the SE. In HCE-based transactions, the communication is routed to the host processor in the mobile phone. The Android KitKat 4.4 HCE service routes transactions using application and service selection methods. Application coexistence is enabled by means of AID-specific routing. The NFC controller on the device maintains a routing table that lists AIDs for some of the applications on the device and their associated routing rules. When a contactless reader sends an ISO ‘select AID’ command to the device, the NFC controller identifies the particular application and matches it to a rule in the routing table. Based on that rule, the destination is then identified as host processor (using HCE) or SE, and commands are routed accordingly (Figure 23).

73 Rooting allows someone using a device running the Android operating system to attain privileged control. Jailbreaking is the process of removing limitations on iOS, Apple's operating system.

Figure 23. Routing Options for NFC Payment Transactions AID-specific routing supports the coexistence of applications relying on HCE or the SE in the same device. This capability provides an opportunity for applications to share AIDs. The ability to do partial AID matching74 is facilitated through the different NFC controllers. Android KitKat 4.4 also supports the definition of a default route when an AID is registered in the routing table. When partial AID matching is not supported and an AID set in the routing table cannot be found, the default route is used automatically. An application can be implemented to give users the ability to select an appropriate mode of payment when the HCE implementation supports multiple routing options. This option also allows multiple solution providers and issuers to participate and offer their payment solutions on the same mobile device.

6.2.2.4 Impact of HCE on the Payment Ecosystem HCE and its endorsement by the payment networks represent an opportunity for issuers and solution-providers alike to create new payment solutions.

6.2.2.4.1 Independence from Secure Element Issuers In the SE-based NFC wallet, the SEs are owned by OEMs or MNOs, and the SE is a valuable asset. This ownership model requires all participants to execute contractual agreements with the SE’s owner for using the SE. The owner designates a space (i.e., security domain) inside the SE for each issuing bank and grants the issuing bank access to it. This operation is performed by connections through the TSM infrastructure of the issuing bank and SE issuer. This model implies a triple dependency for issuing banks on the SE issuers: 1) Business dependency: Commercial agreements must be established for “SE rental.” 2) Roadmap dependency: Deployment of the bank service to its customers is contingent on SE issuers massively deploying SEs to their customers (NFC SIMs for MNOs, or embedded SEs for OEMs), as well as implementing and integrating with the TSM infrastructure. 3) Brand dependency: In many cases, SE issuers (i.e., MNOs) define the user experience through their own branded wallet application, and bank issuers are exposed only as a sub-brand within the application, often side-by-side with their competitors. HCE removes the role of the SE issuer and the associated dependencies for issuing banks.

6.2.2.5 Development and Deployment for Basic Services With HCE, service providers can design, develop and deploy services in an autonomous way. Retailers can add NFC payment to their existing application (e.g., as in the case of Tim Hortons). Google’s open access HCE implementation for Android apps frees developers and other members of the ecosystem from dependency on the owner of the SE. App developers anywhere can build apps to support custom contactless applications for loyalty, access, coupons, transit, and closed loop payments. A host card emulation app is identified by a unique AID. HCE on Android supports the organization of AIDs into groups and categories. Transactions can be routed to the SE when appropriate; an app can be identified as a payment or non-payment app. Android HCE is built as a service model; it can be activated when a transaction takes place and execute in the background, rather than having to be started every time a transaction occurs. This feature can support multiple simultaneous use cases without requiring user intervention at every transaction.

74 Partial AID matching may be used depending on NFC controller memory requirements.

6.2.2.6 POS Acceptance Process Apps that use HCE to support contactless payment must comply with the same specifications as apps that rely on the SE. HCE therefore has no impact on the POS application. Payment brands can continue to use their current contactless specifications; where the credentials are stored is transparent to the POS. Communication with the POS is still based on the ISO/IEC 14443 standard and EMVCo specifications, Book D.75 As already mentioned, an HCE payment application is likely to use tokenized credentials rather than static payment credentials. In order to ensure that no modification is required in the acquiring infrastructure, the tokens, parameters, cryptograms and commands exchanged between the POS and the HCE application will have to keep the same format already in place for contactless bank cards and SE-based mobile applications.

6.2.2.6.1 Consumer Perspective For the consumer, the experience at the POS will depend on the specific HCE-based payment implementation approach. For example, if the payment approach uses tokens, it is likely that one or more tokens will be stored in memory on the mobile device. When the consumer taps the phone at the POS, the phone must be powered so that the token can be retrieved and sent to the POS. If the token is valid, the transaction would process as a normal contactless, tokenized transaction. However, if the token has expired and no other token was available on the device, a network connection would be needed to download a new tokenized payment credential from the cloud. The tap may take longer or, if no network connection is available, the consumer may not have a valid payment credential to use. With current tokenization specifications, tokens may not be able to be used with offline POS terminals; tokens must be authenticated in real-time. In an HCE implementation that uses tokens, the transaction would be rejected if the POS terminal is offline. It is also important to note that additional user authentication could be required for HCE-based solutions.

6.2.2.6.2 Other Potential Uses The use of HCE can enable a wide range of value-added retail applications that leverage the NFC interface, such as combining offers, coupons, or loyalty with payment. Because communication between the app and the POS complies with the ISO/IEC 14443 standard, any value-added applications should use the same protocol to optimize transaction times. Note, however, that there are no standards for value-added services. Implementations are provider specific, although certain companies and organizations such as GSMA are working on specifications; some specifications are currently available under license.

6.2.2.7 Hardware Security vs. Risk Mitigation The security model of an SE implementation relies on its strong hardware security and the tamper-proof SE chip. The level of protection and assurance that the SE provides allows the payment brands and bank issuers to provision a payment credential to the mobile device, exactly like the ones that are loaded on physical cards during the production process. Once stored in the SE, the credential may be used for payment until its expiration date, or until the user decides to deprovision it. With an HCE implementation, the equivalent approach would consist of storing the same payment credential inside the HCE service. However an application running on the mobile OS is

75 EMV Contactless Specifications, EMVCo, http://www.emvco.com/specifications.aspx?id=21

much more exposed to malicious attacks than an applet in the SE, and the risk associated is too high for payments. To enhance security, HCE implementations may use white box cryptography and software tamper proofing and be supplemented by techniques such as device fingerprinting. However, a practical HCE payment implementation may also need to incorporate risk mitigation techniques, such as tokenization, device fingerprinting, geolocation, and risk-scoring prior to authorization. Strong user authentication or storage of credentials in a TEE or SE could help to further reduce the risk.

6.2.2.8 Summary of HCE Impact on Payments Ecosystem The international payment brands have defined specifications supporting HCE-enabled NFC payment applications. The specifications support both the contactless magnetic stripe data protocol and contactless EMV. NFC mobile payment transactions carried out using HCE specifications are therefore likely to be considered card-present transactions, depending on payment network policy. However, as described above, the customer experience may not be comparable to what is experienced when credentials are stored in the SE and other risk mitigation approaches may be required to bolster the security of HCE payment implementations.

6.2.3 NFC and EMV As described in Section 3.2.1, the global payments industry is migrating from magnetic stripe bank cards and infrastructure to EMV chip cards and infrastructure. EMV is an open-standard set of specifications for smart card payments and acceptance devices. NFC mobile contactless payment transactions between a mobile phone and a POS terminal use the standard ISO/IEC 14443 communication protocol currently used by contactless EMV credit and debit cards. NFC-enabled mobile phones will be able carry one or more payment applications and accounts from different issuers; the NFC specifications don't define or specify the payment application. NFC payment applications will follow the payment brand specifications for the region of the world where they are being issued. An EMV payment application and account would be loaded in the NFC-enabled phone and used with compatible EMV POS terminals. EMVCo, the organization that manages, maintains and enhances the EMV specifications, has been active in defining the architecture, specifications, requirements and type approval processes for supporting EMV mobile contactless payments. This effort has been critical in supporting the launch of NFC mobile contactless payment in regions that have already migrated to an EMV- based payments infrastructure. Since both NFC technology and EMV payment cards are being introduced into the market over the next few years, merchants should select and install POS terminals that support both capabilities when upgrading their POS infrastructure.

6.3 Comparison of Mobile Payment Approaches As discussed in Section 6.1, the following technologies are available (or have been announced) that can enable mobile payment:  Mobile handset with integrated NFC  Non-integrated NFC and contactless devices, such as stickers, microSD cards, key fobs, and similar form factors  Bar codes  Mobile phone initiated payments in the cloud  SMS text messaging Each technology has advantages and disadvantages, and they are not mutually exclusive. A single device can accommodate multiple types of mobile payments. At least in the short term, it

is likely that no single technology will prevail. Just as consumers can currently choose whether to pay with cash, use a magnetic stripe credit card or a PIN or signature debit card, or write a check, they will be able to choose between different types of mobile payments, depending on the circumstances (e.g., using a bar code at a merchant who has adopted that technology or tapping the phone for NFC payment at a different merchant location).

6.3.1 Review of Mobile Payment Approaches This section reviews and evaluates the different approaches to mobile payments. Table 11 summarizes the results.

6.3.1.1 Mobile Handset with Integrated NFC The concept of implementing NFC-based mobile payments on a handset with an integrated SE or using host card emulation continues to attract attention. Until recently, the adoption of NFC has lagged, due in part to adoption being a “chicken-and-egg” problem. While this method of payment requires a POS terminal capable of accepting contactless transactions, relatively few merchants have installed appropriate terminals. Therefore, consumers cannot use their contactless devices in many places, discouraging adoption by more consumers. The migration to EMV, with POS terminals being replaced to support chip, provides an opportunity for merchants to upgrade to support NFC mobile payments at the same time. Also critical to widespread availability is agreement among the different business partners involved on a business model. With Apple’s introduction of Apple Pay, Google’s acquisition of Softcard and use of host card emulation, and Samsung’s announcement of Samsung Pay, there is a strong likelihood that NFC is poised to become the dominant mobile payments technology. NFC-based payments are processed through a payment brand and are therefore suitable for payment over both open-loop merchant networks and restricted access networks. NFC-based contactless payments are extremely secure; there is no empirical evidence to the contrary. However, NFC technology is new to consumers, and they require education regarding its safety and security. There is a perception by consumers that NFC may be unsafe (“What if I lose my phone?”) when in fact there are numerous ways to protect the phone’s wallet beyond the standard account management processes for rapidly blocking transactions from a specific PAN (primary account number), including the ability to protect access with a PIN and disable information on the handset remotely. The benefits of NFC mobile contactless payments include the following:  Handsets are more ubiquitous than credit cards; consumers are more likely to have their phones with them than a traditional wallet or purse.  The processing power of the handset supports a robust interface and the ability to integrate core payment functionality with other applications.  The wallet interface can support value-added applications such as loyalty programs.  Payment credentials can be stored in the mobile device as tokens and be accessible through an application that can be protected by a passcode or biometric.  Existing payment networks and the growing infrastructure for card-based contactless payments can be leveraged. The challenges with NFC contactless payments include the following:  A limited number of integrated NFC handsets are currently available in the market that can support the new NFC mobile payments solutions.

 The business relationships will continue to evolve and are probably more complex than for any other solution, presenting some risk and potential consumer inconvenience.  Physical POS hardware upgrades are required for merchants who currently do not accept contactless payments. Installed contactless POS terminals may require application or software upgrades to accept NFC contactless payments.

6.3.1.2 Stickers / microSDs / Other Non-Integrated Devices Stickers, microSDs, and similar approaches (e.g., key fobs, watches) allow a consumer to use a device other than a mobile handset to transmit payment credentials to a contactless POS terminal. While some of these approaches are more robust than others, many of them are essentially identical to the use of a contactless card in terms of data personalization, security, and functionality. In all cases, fulfillment is required, and personalization solutions other than the standard credit card personalization process may also be required. Fulfillment is often performed by the issuing bank, which delivers both a standard card and the alternate device (often referred to as a companion device). In many cases, the peripheral device is restricted to a single payment credential. Some of these solutions are partially integrated with a mobile handset, using a microSD slot, for example, that takes power from the phone. There are also standalone devices, such as key fobs, and devices that are intended to be affixed to a handset or other surface. In some cases, these devices are used as a supplemental prepaid device that is linked to another account and may be reloadable. The benefits of using microSDs and other contactless devices include the following:  Deployment can move more quickly, because availability of the devices is not tied to the availability of handsets and OTA provisioning services.  Issuers can leverage the existing provisioning infrastructure for personalization and delivery of the device.  The payment networks and the growing infrastructure for card-based contactless payments can be leveraged.  MicroSD solutions can be integrated with the phone, provide the same level of security as integrated NFC, and provide a richer user experience than other non-integrated approaches. The challenges with using microSDs, stickers and other contactless devices include the following:  Non-integrated solutions can provide more options for distribution, but may add more complexity for supply chain deployment (e.g., inventory, supplier management).  Non-integrated solutions (e.g., stickers) may not provide a user interface.  The performance of non-integrated solutions can be affected by the physical phone design (e.g., phones with metal bodies).  Stickers typically are from a single issuer, providing less flexibility for the consumer.  Some mobile devices don’t allow for use of microSD without additional accessories or certifications.

6.3.1.3 Bar Codes The market already uses multiple bar code technologies, and they all have the same advantages and disadvantages. The best known example of the use of bar codes is the Starbucks implementation, which allows a consumer to have a 2D bar code sent to a mobile device for execution of a Starbucks Card

transaction. The implementation is a closed system implementation; it applies to one merchant only and allows the consumer to execute a payment on a proprietary system. The bar code is scanned at the POS and the customer’s Starbucks Card account is charged accordingly. The bar code does not implement any type of dynamic data technology as part of the transaction authentication process. A more open bar code implementation is certainly feasible. The Merchant Commerce Exchange (MCX) announced that it is building a merchant-owned mobile commerce network that will be used by multiple retailers. The MCX mobile payment product, CurrentC, is expected to be launched in 2015 and be based on bar code technology.76 The benefits of bar codes include the following:  The technology is proven in the store and well understood by consumers and cash register operators; most merchants already have the ability to scan a bar code.  Bar codes can be implemented as single use to enhance security, and bar code apps can be protected with a pass code.  Bar code-based systems may bypass the traditional bank card payment processing system, enabling different payment types and value-added applications to be implemented by the retailer. The challenges with bar codes include the following:  Some users have reported problems with the reliability of the scan; multiple presentations are sometimes required. If a user has lowered the brightness of the screen to conserve energy, the ability of the scanner to read the bar code may be affected.  The device must be powered in order to access the bar code (other solutions, such as stickers, do not have this requirement).  Merchant POS imaging reader terminals can more expensive than contactless/NFC readers.  Presenting the bar code may require the cashier to take the device from the customer to scan the bar code.  Bar codes may not be readable in certain environments, such as in direct sunlight or bright light.  Bar codes implementations that are not single-use present opportunities for increased fraud.

6.3.1.4 Mobile Phone-Initiated Payments in the Cloud In the payments in the cloud scenario, the consumer is able to manage payment credentials using a cloud-based application. Payment is executed using an application to which the merchant and the customer have both subscribed. Consumers access the cloud-based application through their mobile phones, using e-mail, a mobile browser, or a dedicated mobile application. Payment notification can take a number of forms (e.g., e-mail message, SMS message, sound). Examples include PayCloud Mobile Wallet for loyalty cards and gift cards, and PayPal. Many efforts in this area have focused on closed system applications, such as retailer gift cards, but open systems payments are certainly feasible. The benefits of payments in the cloud include the following:

76 Merchant Commerce Exchange, http://www.mcx.com/

 The solution may be lower cost for the merchant, if an alternative payment type is used.  Consumers are familiar with similar solutions (e.g., PayPal).  Implementation can be relatively easy for merchants since new POS hardware may not be required.  Merchants have better ability to customize and differentiate applications.  The solution is scalable. The challenges with payments in the cloud include the following:  Cloud payments require a connection to the cloud. A transaction may be interrupted or not be possible due to connectivity issues.  Transactions may be slow, depending on how the wallet is accessed, what the connection speed is, and how much data must be entered.  Specific mobile phone capabilities may be required.  Deployment of a peripheral POS device may be required (for example, to support the use of ultrasonic frequencies). The POS would need to be enabled to pick up audible transaction information.  Both the merchant and the consumer must subscribe to the cloud-based service.  There may be security issues (e.g., using SMS or email vs. secure storage and transmission).  The merchant may need to sign up for a service or install a non-standard application for payment processing. The existing payments infrastructure is not leveraged.  Some cloud-based transactions have been treated as card-not-present transactions, resulting in higher transaction fees.

6.3.1.5 SMS The SMS approach requires consumers to register their mobile numbers with a service that manages back-end funding accounts. This same service sends text message codes to consumers in response to merchant-initiated transactions. The consumer then provides the code to the merchant as proof of payment. The transaction is completed by a processor and settled back to the merchant. One approach to SMS-based payments aggregates small charges and bills them to a mobile phone account. SMS can also serve as a channel to other back-end settlement solutions. To execute a payment using SMS, consumers send an SMS text message from their phones to transfer funds or pay for goods and services. The advantages of SMS include the following:  The solution is universal. SMS works on any phone with text messaging capability and does not require a special browser. SMS works with any carrier service.  SMS is a highly scalable technology.  The solution is low cost, although carriers are beginning to charge issuers for SMS text messages.  Consumers are familiar with SMS text messaging, so the learning curve is low.  SMS works well in countries with poor Internet and POS infrastructure. The disadvantages of SMS include the following:

 SMS is necessarily “low tech” and rudimentary, allowing for simplicity and scalability but limiting functionality.  Mobile carriers have been averse to the risk management requirements and liability associated with extending credit under a carrier billing solution. To date, these solutions have been limited to low-value transactions.  Knowledge of the text message recipient’s telephone number is required.  Use of SMS does not guarantee delivery. Messages may be delayed or not delivered at all.  The solution requires mobile connectivity, so it will not work in areas without service.  SMS-based payments lack the high degree of security inherent in a chip-based solution.  The merchant must sign up for SMS service or install a non-standard application for payment processing. The existing payments infrastructure is not leveraged.

6.3.2 Evaluation Criteria The approaches to mobile payment described in the previous sections were evaluated on the basis of the following criteria:  Reliability at the POS  Transaction speed  Security  Ease of use  Wallet functionality  Merchant acceptance/deployment  Device deployment/availability  Additional value-add applications Reliability at the POS. Reliability at the POS measures the extent to which a consumer can expect that a transaction will be completed successfully. Depending on the approach, limiting factors could include (for example) the read range between devices, the ability of a scanner to accurately read a bar code, the availability and strength of any wireless networks involved, or the complexity of an application. Transaction Speed. Consumers and merchants are accustomed to fast POS transactions, with payment complete within a few seconds. Each mobile payment approach has a different process for the merchant accepting payment. Factors that contribute to slower transaction speed include the amount of interaction the consumer must have with the mobile phone, the speed of the mobile connection, and the process of communicating the payment information from the phone to the POS system. Security. Security measures the ability of the device or the application to protect payment credentials or other sensitive customer data. Ease of Use. Ease of use measures the “user friendliness” of the customer’s payment experience using an application. It considers how simple the process is and how much training the consumer and the merchant’s employees need. The more a solution minimizes the introduction of new processes and leverages elements with which the consumer is already familiar, the greater the likelihood that the overall experience will be positive. A completely new customer interface or interaction incurs greater risk that the consumer will not be engaged. Wallet Functionality. Many mobile payment approaches use a wallet on the mobile device to hold payment account information. Wallets can also support coupons, promotions, and loyalty programs. Wallets provide increased convenience for consumers by aggregating the payment

and payment-related applications in a single user interface. Wallet functionality measures how much support the mobile payment approach provides for a wallet. Merchant Acceptance/Deployment. Merchant acceptance/deployment measures the likelihood that merchants will accept and deploy the payment method. In some cases, acceptance will be nearly universal, while in others it may be initially limited with uneven prospects for acceptance. For example, if a method requires significant merchant-level system changes and POS hardware upgrades, these requirements will affect the rate of merchant deployment. This criterion examines factors such as the extent to which the payment method requires infrastructure investment and the likelihood that merchant acceptance can increase quickly. Device Deployment/Availability. Device deployment/availability considers whether the payment method relies on distribution of a new device to the consumer or whether it can leverage a device the consumer already has. If a new device is required, this criterion considers whether the infrastructure and capability to distribute it are in place. The requirement that the consumer acquire a specific mobile handset or peripheral device will affect consumer acceptance. In some cases, consumers will be able to use devices they have but will be required to download an application, register for a service, or take another action. The less a consumer has to do, both in terms of effort and cost, the greater the likelihood of broader acceptance. Additional Value-Add Applications. The mobile phone provides the platform for a wide variety of applications. This criterion measures the extent to which the mobile payment approach can support additional value-add applications such as coupons, promotions, and loyalty programs.

6.3.3 Comparison of Approaches to Mobile Payment77 Table 11 presents a summary of how the alternative mobile payment approaches meet the criteria in Section 6.3.2 based on the benefits and challenges described in Section 6.3.1. Over time, these ratings will undoubtedly change, based on maturity of the solutions, changes in the acceptance environment, and other developments.

77 The ratings in this section were based on the Smart Card Alliance Payments Council’s review of the different payment approaches versus the criteria discussed in Section 5.2.

Table 11. Comparison of Alternative Mobile Payment Approaches Integrated Stickers, Bar Payments in MicroSD SMS NFC Fobs Codes the Cloud

Reliability

Transaction Speed

Security

Ease-of-Use

Wallet Functionality

Acceptance

Device Availability Additional Value Add Applications

Legend WORST BEST

6.3.4 Summary A review of the various mobile payment solutions in the market leads to the conclusion that the marketplace will include multiple solutions for a considerable period of time. However, it appears likely that mobile NFC handsets will grow to be a dominant mobile payment solution. Cloud- based solutions are also likely to play a significant role, given the potential for lower cost approaches with cloud-based applications. Ultimately, the ability to leverage existing payment system assets securely, in combination with enhanced mobile solutions for loyalty and offer management, will drive significant growth in NFC handset-based mobile payments.

7 Secure Remote Transactions: Retail E-commerce78 Industry reports are forecasting that card-not-present (CNP) fraud is expect to grow. Card-not- present fraud involves the unauthorized use of a credit or debit card number to purchase products or services in a setting where the customer and merchant are not interacting face-to-face. This can be in an Internet (or e-commerce) transaction from either a computer or a mobile device, or a transaction that takes place over the telephone or through mail order. Two factors are impacting the growth in CNP fraud. First is the projected growth in e-commerce. According to the U.S. Department of Commerce, total e-commerce sales for 2014 were estimated at $304.9 billion, an increase of 15.4 percent from 2013. E-commerce transactions are also projected to be a growing fraction of total transactions. E-commerce sales in 2014 accounted for 6.5 percent of total sales, compared to 5.8 percent of total sales in 2013.79 Second, addressing CNP fraud risk is an important topic as countries move to EMV chip payments at the physical point-of-sale (POS) to address the growing problem of counterfeit fraud. Experience in other countries, however, has found that as counterfeit card fraud declines, fraudsters move to other channels, such as e-commerce, and CNP fraud increases as a proportion of total fraud. The U.K. experience supports the prediction the CNP fraud will grow. The move to EMV payments in the U.K. left CNP transaction authentication unchanged. CNP fraud in the U.K. grew rapidly from the start of EMV deployment in 2003 until it peaked in 2008. Beginning in 2008, CNP fraud declined for several years as merchants implemented a more secure authentication protocol for Internet transactions (3-D Secure) and as magnetic stripe-only locations in continental Europe decreased, thus reducing the opportunity to use counterfeit magnetic stripe cards. (Figure 24) Data from the U.K., France and Australia80 show that CNP fraud became a larger portion of overall fraud during and after their EMV chip conversions, as EMV chip dramatically reduced the card-present fraud issues but did not address the card-not-present fraud problem. Spain took a different approach to card-not-present fraud during its migration to EMV technology. The difference between Spain’s experience and the U.K.’s experience was described in a TSYS white paper.81 The charts below illustrate the impacts from different approaches and priorities for mitigating fraud, depicting the complexity of the problem and the need for a comprehensive, sustained effort to combat it.

78 Content in this section is an extract from the EMV Migration Forum white paper, “Near-Term Solutions to Address the Growing Threat of Card-Not-Present Fraud,” April 2015. 79 “Quarterly Retail E-Commerce Sales, 4th Quarter 2014,” U.S. Department of Commerce, Feb. 17, 2015. 80 “Card-Not-Present Fraud: A Primer on Trends and Authentication Processes,” Smart Card Alliance, February 2014 81 “EMV is Not Enough: Considerations for Implementing 3D Secure,” TSYS white paper, by Jonathan D. Hancock, 2013, http://www.tsys.com/Assets/TSYS/downloads/wp_emv-is-not-enough.pdf

Figure 24. The U.K.’s Focus on EMV Deployment vs. Spain’s Preference for 3D Secure.81, 82 E-commerce retailers and the payments industry currently take a variety of approaches to authenticate consumers and a variety of solutions to address CNP fraud risk. This section reviews some of the near-term solutions for addressing CNP fraud that were assessed as best practices by the EMV Migration Forum CNP Fraud Working Committee.

7.1 Authentication Methods Identity authentication for a card-not-present transaction – one that is requested by a consumer not present at the retail merchant location – is defined as the process of ensuring that the owner of the account being used to pay for the purchase is performing the transaction. Identity authentication in this context typically relies on a person providing one or more of the following authentication factors:  Something the person has, such as a payment card (ownership factor).  Something the person knows, such as a PIN (knowledge factor).  Something the person is or does, such as a fingerprint (inherence factor). This section examines the following authentication methods, which were identified as the best practice authentication methods by the EMV Migration Forum CNP Fraud Working Committee:  Device authentication  One-time password  Randomized PIN pad  Biometric factors

82 “Evolution of Card Fraud in Europe 2011-2012.” Fico.com. Web. November 2013, http://www.fico.com/landing/fraudeurope/Evolution_Europe.html

7.1.1 Device Authentication Device authentication, deployed primarily by financial institutions and e-commerce merchants, authenticates the device being used to access the merchant’s e-commerce site (e.g., smart device, personal computer or tablet). The method authenticates the device based on multiple device characteristics (e.g., device type, operating system, IP address) acquired either before or during a transaction. Defining the exact characteristics that identify an individual device can be complicated. The identification software can be homegrown or purchased from a third party. Multiple services are available from third-party providers. Companies that track the successful and fraudulent transactions associated with the devices can assist in their authentication. Because this method authenticates the device and not the cardholder, additional authentication is required to protect against the use of lost or stolen cards. Device authentication does not address mail order or telephone order (MOTO) transactions. In combination with other authentication techniques, device authentication can reduce the risk of fraudulent transactions. One potential complication is that different providers may use different characteristics to define devices.

7.1.2 One-Time Password A one-time password (OTP) is a password that is only valid once. Since OTPs are dynamic and cannot be reused, their use can prevent replay attacks. Additionally, OTPs are often implemented to be time sensitive, either because they are generated during a valid transaction or because they are time-synchronized with the entity that generates them. Unlike other tools, OTPs can feasibly be used in all CNP channels: Internet, telephone, and mail order. A method is required to deliver OTPs to users. Common delivery methods include hard or soft tokens, display cards, text messaging, and Internet-based channels. Delivery is also possible using paper or other physical media (e.g., scratch cards) in countries where electronic delivery methods are not practical. If the delivery method is out of band from the transaction being performed, OTPs can be an effective component of two-factor authentication. Methods for generating OTPs include random generation, mathematical algorithms, and time- synchronized algorithms. The method chosen for OTP generation and delivery directly affects and increases the strength of OTP as an authentication solution. The following three solutions reflect stronger authentication:  Truly random generation and one-way algorithms since the OTP cannot be reverse engineered.  Integrating OTP with other methods since the OTP by itself is susceptible to “man in the middle” and phishing attacks.  Reducing the timeframe when an OTP is valid. OTPs must be paired with user IDs or card numbers, and security is often layered with a static password, PIN, or pass phrase.

Figure 25. Example of OTP delivery; from left to right: display card integrating payment function and OTP generator, SMS OTP, discrete OTP token

If a display card feature is added to an EMV chip card, the card manufacturer will need to have the card certified and approved in the same fashion as a standard EMV chip card. Adding this feature to a card without a PIN pad nullifies the protection OTP offers against the use of lost or stolen cards, since the fraudster can supply the OTP being generated on the card. Use of an existing mobile device to generate or receive an OTP obviates the need to obtain and carry an additional device, display card or token to generate or receive OTPs. These solutions, although serving similar purposes, have a wide range of cost considerations, driving some stakeholders to favor one particular method over another.

7.1.3 Randomized PIN Pad The randomized PIN pad authentication method allows consumers to enter a PIN to complete a transaction and use their PIN-enabled debit or credit card for e-commerce purchases. This method can also be used for one-time PINs, as described in the previous section and for credit card POS PINs, as described below. When consumers indicate they want to pay using a card from a bank that contracted for this method, a PIN pad floats on top of the e-commerce merchant’s checkout page (Figure 26).

Figure 26. Example of a Virtual PIN Pad The consumer uses their pointing device (a mouse or their finger for a touch screen) to enter a PIN (thus preventing key logging). After each mouse click, the keypad is scrambled, and only the XY coordinates of each click are captured. When the PIN and other card data have been entered, the customer submits the transaction. The XY coordinates that represent the PIN are encrypted and sent to a data center, where they are converted to PIN characters and encrypted according to industry standards in a hardware security module (HSM). The PIN is never in the clear or stored at the merchant location.

PIN data-request details are combined with the other authorization data to form an ISO/IEC standard 8583 message, which is sent to the issuer for authorization. The authorization response message is then returned to the merchant from the issuer’s authorization system. Many merchants currently use a randomized PIN pad to authenticate e-commerce transactions. Consumers in the U.S. can use PIN-enabled debit cards to make e-commerce purchases without having to register on the merchant’s web site (and enter data such as a user name or password) or leave the site. Credit cards with PINs used at the point of sale can also use the random PIN pad for Internet purchases. Some chip-enabled credit cards in the U.S. may require the use of a PIN at the POS. Typically, magnetic stripe-only credit cards in the U.S. do not, although a PIN is required to obtain cash from an ATM. As some U.S. credit cards become chip and PIN enabled, beginning in 2015, they will be eligible for using the random PIN pad solution, assuming their issuers support the feature. The same randomized PIN pad process can be implemented for PCs, laptops, tablets, and phones, thus standardizing the payment process across many different platforms. The randomized PIN pad can be used for both static PINs and one-time use PINs. Randomized PIN solutions are supported by various issuers, processors and merchants across the U.S.

7.1.4 Biometrics While biometric authentication can be implemented across many types of consumer devices, this section is focused on implementations that authenticate a cardholder from a smartphone during a CNP transaction. Now that digital cameras have become a core feature of most smartphones, these devices can be used, in conjunction with required software, to perform facial recognition alongside voice recognition of a cardholder during a CNP transaction. Fingerprint scanners are also now available in a number of smartphones and can be used to authenticate a cardholder during a CNP transaction. Facial and voice recognition solutions typically perform their verification with a secure database server while fingerprint scanners that are embedded in smartphones typically perform verification in a secure location directly on the device. Use of biometrics to authenticate a CNP transaction offers benefits and challenges. One benefit is increased reliability of identity authentication. The challenges depend on the type of biometric used and the channel through which it is implemented. While a promising technology, use of biometrics raises both privacy and liability concerns. Given the sensitive nature of biometric data, the data should usually be transmitted out-of-band unless a very secure in-band transmission technique is available. Not all types of biometrics may be appropriate for use with all CNP transactions, and implementers may wish to consider related factors such as implementation costs, reliability and user friendliness. Smart devices can authenticate consumers in-band, using a mobile app on the phone to perform the transaction, or out of band, when another device is being used. Out-of-band e-commerce biometric authentication protects against most known attacks, such as man-in-the-browser (and its variations). Information describing the transaction can be shown on the smart device screen before the transaction is completed. If the displayed transaction information does not match the actual transaction, the consumer is able to decline the transaction. Biometrics cannot be shared or easily copied. The mobile application can be protected with a PIN/passcode to increase security, although requiring it may reduce the user friendliness of the solution. An optional secure element (SIM card, micro SD, or embedded secure element) or trusted execution environment in the smart device, managed by a trusted service manager, can further protect the biometric data and application.

7.2 Fraud Tools Two best-practice fraud reduction tools were identified by the EMV Migration Forum CNP Fraud Working Committee.  Proprietary data/transactional data  Validation services

7.2.1 Proprietary Data/Transactional Data Proprietary and transactional data can be collected by merchants, issuers, and acquirers and used to enhance risk management and fraud prevention activities. Proprietary data, defined as data owned by a single organization (merchant, issuer, or acquirer), has proven to be invaluable in identifying fraudulent payments. An example of proprietary data used in this way is a list of high-risk payment cards, e-mail addresses, IP addresses, and similar information, which is accrued over time by a merchant (i.e., a customer history). Transactional data is data collected at payment, either explicitly (e.g., name, ship-to address) or implicitly (e.g., web connection details). These data elements are specific to a single transaction. Before a merchant delivers a product or service, the associated payment-transaction data (e.g., buyer, payment method, endpoint/device, web connection, order details) can be analyzed to determine whether the transaction is likely to be fraudulent. This data can be gathered in a number of ways: scripts on a merchant’s payment page, the browser or native mobile app request from the customer, proprietary intelligence collected over time, and order-related information provided by customers themselves. Once the customer completes a purchase, data collection is the first step in the risk management process The data are either collected in real time (transactional data) or accessed as needed (proprietary data). All transaction details must be securely logged. Next, a rules engine that incorporates industry or homegrown fraud tools (such as velocity checks and dynamic order linking) analyzes the data, applying the rules or parameters defined by the decision maker. The results of this analysis are then used to calculate a fraud score, which is returned to a decision maker (merchant or acquirer) who can choose to approve or decline the transaction. When an authorization request is received, a card issuer can use similar data (although typically not endpoint device data) to develop its own score and authorization decision. The types of data used to calculate a fraud score are determined by the type of risk being evaluated. Some examples are device attributes, web connection attributes, payment details, buyer information, order form attributes, and proprietary history. The fraud prevention model can be further enhanced through leveraging shared industry data.

7.2.2 Validation Services A validation service uses customer information other than a primary account number (PAN) to validate that the actual card account holder is participating in a transaction. A number of validation services are available. Merchants can adopt a single service, using a single control checkpoint, or multiple services, as a layered control check, with the option of accepting transactions at any point to reduce consumer friction. Each control point offers an additional opportunity to help reduce fraud. The two predominant validation services are the address verification service (AVS) and card security code (e.g., CVV2, CVC2, and CID). Other validation services which match additional

data elements (e.g., e-mail address, phone number) may provide tighter fraud screening but often require additional costs and resources.

7.2.2.1 Address Verification Service AVS requires that the purchaser enter the billing address on file for the card. The issuing bank generates one of the following response codes, based on the numeric portion of the address line 1 and the zip code data that are passed as part of the transaction:83  Full match. Both address and zip code match the billing information on file with the issuer.

 Partial match. The address matches but the zip code does not, or vice versa.  Complete mismatch. Neither the address nor the zip code match.  AVS not supported by issuing bank.

 System/technical error. The disadvantage of using AVS for transaction authentication is that the consumer must understand the differences between the billing, mailing, and shipping addresses, because the billing address is used most often for AVS matches. Additionally, it may be difficult to validate foreign cardholders, due to different postal code formats. Postal code formats might not be available in all markets.

7.2.2.2 Card Security Code Validation Service Card security code validation requires the purchaser to enter the security code printed somewhere on the physical card, for example such as next to the signature panel. The code is an encrypted value determined by elements that include card attributes, such as card number and expiration date. The issuer has the encryption key and can decrypt the code and validate it during transaction authorization processing. This service verifies that the CNP transaction is being conducted by someone who is in possession of the card being used. Dynamic security code, or DCVC/DCVV is also coming into the market where a new security code is periodically and automatically generated instead of using a static security code that is usually printed on back of the card.

7.3 3-D Secure 3-D Secure (3DS), in its current version, is a secure communication protocol used to enable real- time cardholder authentication directly from the issuer during an e-commerce transaction. The payment networks have built proprietary products on top of this protocol. The authentication process is initiated by 3DS software resident on the merchant’s or its service provider’s system; the cardholder is authenticated by a 3DS component operated by the issuing bank or its service provider. Authentication requires the cardholder to communicate a secret that is shared with the bank or that otherwise meets the bank’s requirements. The purchase transaction, enhanced with the authentication data, is then processed through the traditional payment systems (including authorization, clearing, and settlement). 3DS divides transactions into three domains:  The issuer domain encompasses the systems, functions, and relationships of the issuer and its cardholders.

83 Note that actual response values and codes from each issuing bank vary somewhat and may continue to evolve in line with payment network mandates.

 The acquirer domain encompasses the functions of the acquirer and its merchants.  The interoperability domain encompasses the systems and functions that enable the issuer domain and the acquirer domain to interoperate and authenticate each other within participating payment systems. 3DS supports multiple authentication methods, including static passwords, OTPs, the use of a participating bank’s online banking credentials, the use of an EMV chip card reader, and biometrics. It can also be deployed using either a standard model, in which every transaction is authenticated with 3DS, or a risk-based model, in which cardholders require authentication with 3DS only when risk characteristics for a transaction exceed a predetermined level. 7.4 Tokenization Tokenization secures payment data by replacing a primary account number (PAN) with a surrogate value, both to protect cardholder data and to help minimize the impact of a data breach. Tokenization can be very effective in both card-present and CNP channels, including mail order and telephone environments. However, tokenization should only be considered as a complementary fraud-prevention technique. Most of today’s tokenization techniques leave a customer’s PAN in the clear at some point in the payment chain (for example, when a card number is entered in a browser on a consumer’s device or when the number is in the merchant’s system before being exchanged for a token). Multiple strategies are available for using tokens, and there is a recognized need to streamline these approaches and standardize the definitions. This section simply provides a brief introduction to tokenization architecture; the examples are not meant to cover all possible scenarios. A tokenization approach currently used in merchant systems is sometimes called “acquirer tokens.” After the merchant sends the PAN to the acquirer, the acquirer returns a token in place of the card number. The acquirer stores the card number and related token in a secure token vault that can be accessed by the merchant whenever required. Implementing tokenization may reduce the number of systems that must comply with PCI Data Security Standard (DSS) requirements and therefore offers some PCI DSS relief. Since tokenized card data cannot be used to initiate payments, the stored card number data is not valuable to criminals. Tokenizing the card number, therefore, reduces the chance card data acquired inappropriately will be used fraudulently. Other tokenization implementations involve replacement of an original payment credential (e.g., PAN) with an identifier (payment token), which may be used to complete payment and increase security. This approach reduces the risk of fraud from breaches both when used in new technology solutions and in existing payment systems. Additional information on tokenization is found in Section 8.

7.5 Summary To reduce exposure to CNP fraud, merchants, acquirers, and financial institutions must work together to secure all of the sensitive data elements handled during transaction lifecycles. In protecting this data, all parties must be aware of potential effects on users, such as increased transaction times or tactics that make transaction completion more difficult. Several mechanisms can potentially reduce CNP fraud, reducing merchant financial liability and the overall cost of doing business. No single security mechanism can protect against all possible fraud scenarios; rather, a systematic, layered approach must be implemented to secure all transaction data. (Additional information on security layers for card-present and CNP transactions can be found in Section

8.4.) These security layers must be able to protect sensitive data for the entire duration of the transaction. When properly implemented, such an approach will ensure that compromising a single data element does not affect the integrity of the other elements. Moreover, users may find a compelling business case for employing a “combination” approach, where implementing multiple security layers is likely to produce an integrated solution capable of protecting sensitive data.

8 Security Layers Protecting the Payments Infrastructure: EMV, Encryption and Tokenization Data breaches are a “way of life” now – not only for the payments industry but for all industries that have data that can be monetized or used by criminals. According to NetworkWorld, nearly a billion records were compromised in 2014.84 Other statistics point to the scale of the problem.  According to the ID Theft Resources Data Center, U.S. data breaches hit a record high of 783 in 2014, with 150 breaches already reported this year as of March 2015.85  The Ponemon Institute put the average cost per compromised record at $201 with the financial services industry the highest at $316.86  The Target breach cost the company $162M in 2013-1487, and merchant losses due to fraud are increasing – to 0.68% of revenue in 2014.88

Three technologies are being implemented today that work in tandem to protect businesses processing credit and debit cards against card fraud. The three technologies are:  EMV, which improves the security of a payment transaction by providing cryptographic card authentication that protects the merchant and issuer against the acceptance of counterfeit cards. EMV also offers cardholder verification and several means of transaction authentication that help safely authorize transactions.  End-to-end encryption (E2EE) or point-to-point encryption (P2PE), which can immediately encrypt card data at inception – at card swipe, key entry, tap or insertion – so that no one else can read it and monetize the card data.  Tokenization, which replaces card data with “tokens” that are unusable by outsiders and have no value outside of a specific merchant or acceptance channel. This section reviews how payments industry implementation of the three technologies together secures the payments infrastructure and prevents payment fraud.

8.1 EMV Technology The growth in counterfeit card fraud was what originally motivated the global payments industry to move to chip technology for bank cards and to develop the EMV specification for cards based on chip technology (smart cards). The EMV specification defines a global interoperable standard for smart chip-based bank cards. Section 4 provided a detailed review of the benefits of EMV and how the technology works to secure transactions. EMV chip technology plays multiple roles with respect to fraud  It prevents card copying.  It detects counterfeit cards.  It prevents the use of lost and stolen cards (with PIN).  It helps to reduce the value of stolen payment.  It can enable and protect offline transactions. EMV chip technology supports a number of features to reduce in-person card fraud.

84 NetworkWorld, Nov. 17, 2014. 85 Identity Theft Resource Center, March 2015. 86 Ponemon Institute, May 2014 87 TechCruch, Feb. 25, 2015. 88 2014 LexisNexis True Cost of Fraud Study, August 2014.

 Cards include an embedded microprocessor chip that has strong security features making them highly resistant to tampering or making cloned copies of payment cards.  Cardholder data is stored securely inside the chip during personalization. The chip uses security keys and other techniques to provide a secure container for holding the cardholder data -- especially as compared to the magnetic stripe on existing payment cards  In every chip transaction, dynamic data is generated and sent to the issuer to validate that the card is authentic and not counterfeit. This dynamic data is different with every transaction, reducing the likelihood that payment data from one transaction can ever be used to create a counterfeit card or used in counterfeit transaction at a later date.  If card data is stolen during or after a transaction, it can’t be used to create a counterfeit chip card, counterfeit mag stripe card or reused in another card-present transaction. So it helps to reduce the value of any stolen payment data.  If a chip card is swiped at a POS terminal, the terminal will detect that the card includes a chip and ask that the cardholder insert the chip card so that full EMV chip transaction processing can occur. It will detect if a magnetic stripe has been copied off of an EMV card and presented as a counterfeit card.  Chip cards can support online or offline PINS for cardholder verification, providing protection against lost or stolen card fraud. 8.2 Transaction Data Encryption Encrypting transaction data (both cardholder data and other data describing a transaction) can prevent intermediaries, such as hackers, Internet providers, or application service providers, from discovering or tampering with the data. Two approaches to encryption are commonly used to provide such protection: end-to-end encryption (E2EE) and point-to-point encryption (P2PE). In a P2PE solution, the data is decrypted at each stop (e.g., merchant to processor, processor to issuer, issuer to merchant). In an E2EE solution, the cardholder data is encrypted at the point of entry and decrypted only at the intended recipient end. Both methods require an originating party to encrypt data so that it is readable only by the intended recipient. Both methods can simplify PCI compliance requirements for a merchant. Reviewing the overall process of encryption, cardholder data is encrypted as soon as it enters a payment system at the POS terminal or PIN pad; the data remain encrypted until it reaches the processor or acquirer, where it can be decrypted safely and securely, with no involvement of third parties or the merchant in the encryption or decryption process. Using P2PE, cardholder data is encrypted at the point of acceptance; the data is decrypted by the provider, who can be a gateway provider, acquirer, processor, or independent sales organization (ISO). In both cases, the payment processor is responsible for managing the cryptographic keys, as the merchant never has access to the keys or the raw cardholder data. All involved in authorizing and settling the transaction, regardless of whether speaking of E2EE or P2PE, are responsible for PCI compliance. In summary, P2PE and E2EE protect data confidentiality and integrity.

Figure 27. End-to-End Encryption

Figure 27 provides a picture of the flow of a transaction that has been encrypted as noted in zones. In Zone 1 the cardholder data is encrypted at inception – swipe, key, tap or insert. The transaction and encrypted cardholder data passes into Zone 2 which can be a gateway or a network. In Zone 3, the transaction is passed to the acquirer or processor for authorization by way of the card brands. Lastly and in Zone 4, the PAN is stored securely within the processor or acquirer’s PCI certified data center. Transaction data encryption offers the following value in protecting the payment system:  Encryption protects the PAN and/or transaction at rest and in-transit and can be used in both card-present and card-not-present environments.  Encryption eliminates the opportunity for criminals to “monetize” any stolen data. So if data is stolen and it’s encrypted, it can’t be used to effect fraudulent transactions.  It can also reduce scope for PCI Data Security Standard compliance by protecting cardholder data; encrypting data-in-transit; restricting access to cardholder data.89

8.3 Tokenization Tokenization is a process that replaces a high-value credential (e.g., a payment card primary account number (PAN), a Social Security number) with a surrogate value that is used in transactions in place of that credential. Tokenization can map the credential to a new value that is in a different format or that is similar to the format of the original high-value credential (e.g., a payment card PAN in the payments industry). In payments, the objective of tokenization is to remove account data from the payment environment and replace it with something that is useless outside of the environment in which the token was created. While tokenization is not a new concept, recent data breaches have increased awareness of the need to protect payment account credentials. Tokenization is one approach that can be used to safeguard payment credentials from being stolen and used for fraudulent transactions. Merchants using tokenization may be able to reduce the scope of a PCI DSS assessment. There are different kinds of tokens and different ways to create them. A token can be merchant specific. It can be single use or multi-use. It can be stored and managed in the cloud, in a token vault, or at a merchant location. A token is created using a process defined by the token solution provider. Once a token has been created, it may be tied to a card on file, individual transaction, payment card, or device.

89 Coalfire, Heartland Payment Systems E3™ MSR Wedge Technical Assessment White Paper, Jan. 4, 2011, http://www.heartlandpaymentsystems.com/Heartland/files/70/70ce486a-ca66-4c8f-9098- 463900ac2c6b.pdf.

Two types of tokens are being used and/or defined in the payments industry:90 tokens that will function in place of the actual payment account number to perform a payment transaction (called payment tokens);91 tokens that replace the payment account number and are stored by merchants and/or acquirers in place of actual account numbers and used for other uses (called acquirer tokens, acquiring tokens or security tokens).92 The tokenization creation and management process, use of tokens in a payment transaction, and business relationships differ based on the type of credential. Various proprietary tokenization solutions are commercially available and already used by merchants and acquirers to protect cardholder data in both card-present and card-not-present (CNP) environments. New tokenization standards are also being introduced, with ANSI ASC X9 focusing on acquiring tokens and EMVCo focusing on payment tokens (also called EMV tokens).

8.3.1 EMV Tokens In March 2014, EMVCo published version 1.0 of its tokenization specification93 for payment industry participants.94 This specification defines a framework to be used by payment brands, payment issuers, acquirers, merchants, and mobile and digital commerce solution providers to enhance transaction security at various points in the payment process. Various entities are creating token services based on the EMVCo specification. EMVCo tokenization was designed to use current ISO/IEC 8583 message formats that support interoperability with the existing payments infrastructure; the specification adds additional values which may be mapped to existing fields. EMVCo’s tokenization approach is intended to guard against fraud in current CNP channels, such as online account-on-file transactions. Tokens based on the EMVCo specification (referred to “EMV tokens”) can also be used in the card- present channel with EMV chip cards, where a token replaces the PAN that would otherwise be encoded on the chip, while the magnetic stripe and embossing/printing on the card would contain the PAN.95 Lastly, EMV tokens can be accepted in emerging mobile channels whether they are using QR codes, Near Field Communication (NFC), Bluetooth low energy (BLE) or a range of other future possibilities. The intent of the EMVCo tokenization model is to limit risk levels in case of a data breach, and within specific defined domains (e.g., by a specific online merchant or a particular device in a specific acceptance channel). Additionally EMV tokens have an associated token assurance level which is determined by the identification and verification process performed at the time of token issuance. EMV tokens are designed to be interoperable between payment networks. Tokenized payment data is far less attractive to attackers and may eventually reduce data protection requirements for merchants and acquirers. The EMVCo tokenization model introduces a new entity, called a token service provider (TSP). The TSP creates tokens and manages them throughout their life cycle. Token life-cycle management can be implemented using a method such as ISO/IEC 8583 message exchange, batch files, or Web services that are established for secure token-based interactions. The TSP is responsible for managing a registry of entities that can request tokens, a token provisioning

90 Tokenization specifications are currently being defined by the industry, with different names for the types of tokens being proposed. 91 An example of this type of token is discussed in Section 8.3.1. 92 These types of tokens are also being referred to as “security tokens” or “acquirer tokens.” 93 EMVCo, EMV Payment Tokenisation Specification – Technical Framework, Version 1.0, March 2014, http://www.emvco.com/specifications.aspx?id=263. 94 The EMVCo specification defines “payment tokens” or “EMV tokens” that will function in place of the actual payment account number to perform a payment transaction. 95 EMVCo, EMV Payment Tokenisation Specification – Technical Framework, Version 1.0, March 2014, p. 69.

system, token security, token vaults (to secure tokens and PAN mappings), APIs, and detokenization. The APIs allow participants to interact with the TSP. In the EMVCo tokenization model, the token, referred to as a payment token, shares the same overt characteristics of a PAN (including the Luhn check mechanism, bank identification number (BIN) range, and expiration date) to support the current transaction flow and minimize friction in the existing payment processing environment. However, tokens are required to be guaranteed to never collide with PANs. In practice this means that tokens must be issued from separately designated BINs (or ranges within a BIN). Once a token requestor has enrolled with a TSP and identified the domain in which its tokens may be used, the token issuance process starts with a request to a TSP, using a token service API, to tokenize a specific PAN. The token requester can be a merchant, a digital or mobile wallet service provider, a card-on-file system, an issuer, or any other payment enabler. The token is generated within a range of token BINs that are associated with a specific issuer to avoid conflicts with a PAN, and is assigned to a domain within which it can operate. (For example, a token issued for an NFC payment domain will not work in an e-commerce or magnetic stripe environment.) A two-digit token assurance level, similar to a payment instrument risk score, is also assigned to indicate what identification and verification (ID&V) process was done to validate the cardholder’s identity and ownership of the original payment credential; a value of 00 would indicate no ID&V and 99 would indicate the highest level of assurance. The token assurance level can be used by specific programs or for transaction classification and can be influenced by the security requirements for token storage location. ID&V methods can be used for different purposes such as card-on-file account number replacement with a token, or medium or higher assurance level transactions. ID&V methods generally fall into the following categories:  No ID&V performed  Account verification  Risk score derived from the TSP  Risk score derived from token user data combined with payment network data  Card issuer authentication of cardholder Detokenization is the reverse of tokenization and is necessary for transaction processing, settlement and chargebacks. When requested by an authorized and authenticated entity, the detokenization process returns the PAN associated with a token, the associated expiration date, and status. Depending on where the TSP is located in the transaction flow, it may perform the token domain restriction controls directly or provide the transaction processor with the details needed for it to, in turn, perform that task. The BIN plays an important role in routing transactions to the right endpoint. The BIN token range used in transactions will have similar characteristics to the BIN range for the cards and will be part of the BIN routing table distributed to participating entities to support routing of tokenized transactions. Payment tokens have life cycles similar to PAN life cycles. While payment tokens experience their own life cycle events (such as expiration, fraud, loss, transfer of devices, reissuance, theft, changes due to customer profile updates), they may also be affected by changes to the PAN life cycle. The TSP is responsible for communicating changes to the token (or to the PAN associated with the token) to token users in the payments transaction process.

8.3.1.1 Transaction Processing Tokenized payment transaction processing passes the token instead of the PAN, so it becomes the responsibility of the TSP and the payment processing platforms to restrict a particular token to specific payment channels or domains. This restriction will affect the current data fields and

require the definition of both mandatory and optional new fields that have been defined for tokenized transactions. Some of the fields required to control domain restriction are already in place, such as POS Entry Mode, and merchant detail fields. New field use may depend on the specific payment use case, in which merchants, acquirers, and processing platforms may be affected by such use cases.

8.3.1.2 NFC Mobile Payment Transaction Use Case Example Figure 28 illustrates the possible use of EMVCo tokenization in an NFC mobile payment transaction. Tokenization is likely to be used in NFC mobile payment implementations using either secure elements (SE)96 or host card emulation (HCE).97

Figure 28. Use of Tokenization in an NFC Transaction

8.3.2 Summary Tokenization protects the payments infrastructure by removing PAN and transaction data from the merchant environment, protecting data-at-rest and data-in-transit for both card-present and card-not-present channels. Commercial acquiring tokenization solutions are currently available and in use by merchants to remove cardholder data from their business environment (e.g., for loyalty programs or card-on-file transactions). Tokenization standards are also now being developed and published by a number of industry organizations, with commercial solutions starting to use those specifications to provide tokenization services.

8.4 Payment Systems Security Layers The payments industry can provide improved payments protection by using a layered approach. Implementing all EMV, encryption and tokenization and using them in combination can provide a better solution than using any single technology by itself.

96 “Apple Announces Apple Pay,” Apple press release, Sept. 9, 2014, https://www.apple.com/pr/library/2014/09/09Apple-Announces-Apple-Pay.html 97 Additional information on NFC mobile payment using secure elements or HCE can be found in the Smart Card Alliance white paper, “Host Card Emulation (HCE) 101,” http://www.smartcardalliance.org/publications-host-card-emulation-101/.

In looking at how the technologies impact payments security, it’s important to review them versus the types of threats, the types of transactions and the types of channels. From a threat perspective, security approaches need to consider counterfeit cards, lost/stolen cards, re-use of stolen data in fraudulent transactions, theft of data in transit and theft of data at rest. These need to be considered in the context of card-present transactions (where the cardholder is physically present at the point-of-sale) and card-not-present (CNP) transactions (where the cardholder is not present). And lastly, the channel needs to be considered – whether it’s the physical POS, Internet or e-commerce, or mobile.

8.4.1 Card-Present Transactions Card-present transactions include those where customers are in a merchant’s store and are paying with a magnetic stripe card, an EMV chip card or an NFC-enabled mobile device with credentials stored on a secure element on the mobile device. EMV was designed to combat counterfeit card fraud in a card-present environment. Key EMV security features include:  Card authentication using dynamic authentication data (either online or offline), which proves that a card is authentic to the merchant and issuer.  EMV chip transaction data, which cannot be used to create counterfeit magnetic stripe cards if the data is stolen.  Potential PIN addition to an EMV transaction, providing stronger verification of the cardholder identity and addressing lost and stolen card fraud. However, although EMV uses dynamic cryptograms, some sensitive data (such as the PAN and expiration date) that is needed to support routing and legacy system messaging, is sent in the clear during EMV transactions. Encryption can protect transaction data at rest and in transit, whether it’s a magnetic stripe transaction or an EMV chip transaction. A merchant deploying encryption without EMV will not be protected from counterfeit card transactions; EMV technology mitigates the risk of counterfeit transactions. The combination of EMV and encryption protects transactions in the card-present environment. This two-layered approach is a proactive step that merchants can take to protect their card acceptance environment from becoming a source of fraudulent transactions. In addition, tokenization can be implemented in card-present merchant environments to secure data-at-rest. This will most typically be done in order to support the legitimate on-going uses of card data in an inherently secure manner. This is contrasted with encryption, where the encrypted data must typically be decrypted before it can be used. Whenever data is decrypted, it is at risk of being compromised, while tokens can be used without concern as long as the integrity of the token vault is maintained. Use cases include the following:  Some merchants use card information to simplify the return experience for the customers. When a consumer wishes to return an item, the merchant collects the card data, sends it to the token service to be tokenized, and then looks up the transactions in their transaction history.  Lodging merchants may need to perform an EMV authorization upon check-in, but also perform incremental authorizations during the guest’s stay. Instead of retaining the cardholder account number, the merchant may use a token specific to the merchant’s use. The token vault in this case could be at a corporate host or at the acquirer/processor. Similar use cases exist for tokenization in auto rental, equipment rental and other merchant types where a deposit is taken in person, followed by a CNP balance payment.

EMV tokens can also be used in the card-present environment when they have been personalized into a mobile device or onto EMV chip cards. When the consumer is in the store and uses a device with credentials stored on a secure element and accessed through a mobile wallet (e.g., Apple Pay) or on the EMV chip card, the transaction is a card-present transaction and is implemented as an EMV contactless or contact transaction. As with the other card-present use cases, EMV protects against counterfeit credentials and provides card authentication. The merchant may use encryption and/or tokenization to protect the transaction information while at rest or in transit. Alternatively, the issuer can personalize the chip with an EMV token in lieu of the PAN. This will protect all chip transactions from cross-channel fraud (e.g., CNP fraud) in addition to counterfeit fraud.

8.4.2 Card-Not-Present Transactions CNP transactions are those where the customer and merchant are not interacting face-to-face. The customer may be entering payment credentials using a keyboard on a computer, tablet or mobile phone or may have previously provided the payment credentials to a merchant and the merchant uses the stored “card on file” credentials for payment (for individual or recurring payments). As discussed in Section 7, merchants and the payments industry currently take a variety of approaches to authenticate consumers during CNP transactions to help mitigate against CNP fraud. Approaches include static or random passwords, dynamic information such as one-time passwords generated in software or using a smart card or mobile phone, knowledge-based approaches (such as asking secret questions) and device fingerprinting, where some information is used to identify the device by which the user is accessing an e-commerce site. The payments industry has implemented a number of standard approaches for CNP authentication. Asking for the cardholder’s zip code for address verification and entering the “card security code” printed on the card are common methods used by many, but not all, merchants. Card issuers validate that this information is correct during the transaction authorization. The payments networks have also defined the standard 3D Secure authentication protocol that is in use. The 3D Secure software protocol is used by merchants and issuers to validate cardholder identity during an e-commerce transaction. Looking at Europe’s experience, the UK Cards Association reported a one-third drop in CNP fraud since 2007 due to increasing use of fraud screening tools and 3D Secure.98 Online e-commerce merchants typically implement multiple solutions to mitigate CNP fraud or use a commercial service to mitigate transaction risk. Since merchants today assume the costs of CNP fraud as well as typically pay higher fees for e-commerce transactions, merchants also may have their own internal fraud departments and often use tools to score the risk of online shopping behavior to determine which online purchases to accept, reject or send for review. In the card-not-present environment, security approaches should consider:  Some form of cardholder authentication, such as 3D Secure.  Encryption to protect data-in-transit and data-at-rest.  Tokenization to protect data, by creating a token for each CNP transaction that can only be used for that card and a specific merchant. This could be accomplished through either acquiring tokens or EMV tokens. For example, e-commerce merchants can secure cardholder data by implementing the process for card-on-file tokens. The merchant, acting as a token requestor, can request tokens by submitting a token request to a token service provider. The token is provided to the card-on-file

98 “Second Report on Card Fraud,” European Central Bank, July, 2013, http://www.ecb.europa.eu/pub/pdf/other/cardfraudreport201307en.pdf; “Fraud the Facts 2012,” Financial Fraud Action UK, http://www.theukcardsassociation.org.uk/wm_documents/Fraud_The_Facts_2012.pdf.

merchant. The token assigned is specific to the cardholder and merchant domain. If the token were to be compromised, it could not be used anywhere except by the registered user and at the registered card-on-file merchant.

8.4.3 Best Practices Using a layered approach – that is, utilizing all three technologies together – helps to secure the payments infrastructure and prevent payment fraud. Table 12, Table 13 and Figure 29 summarize how each is used to protect transactions. For card-present transactions (Table 12):  EMV technology is the only technology that can protect against counterfeit and lost/stolen cards. It provides some protection against re-using stolen data, but does not address theft of data at rest or in transit.  Encryption and tokenization provide no protection against counterfeit and lost/stolen cards. Both address the threats of theft of data at rest and data in transit.

Table 12. How EMV, Encryption, and Tokenization Protect Card-Present Transactions

For card-not present transactions (Table 13):  EMV chip card technology doesn’t apply since a card reader would be required for an e- commerce transaction and this has not been widely deployed.  Encryption and tokenization provide no protection against counterfeit and lost/stolen cards. Both address the threats of theft of data at rest and data in transit.  Additional approaches need to be implemented for CNP transactions to authenticate the cardholder to protect against the use of stolen payment card data.

Table 13. How EMV, Encryption, and Tokenization Protect Card-Not-Present Transactions

Figure 29: Role of EMV, Encryption and Tokenization in the Payment Ecosystem

The layered security approach is based on the following key guiding principles.  Continued migration away from transactions based on static authentication by implementing EMV for the card-present environment.  Protection of data-at-rest and data-in-transit through the payment process, for both card- present and card-not-present environments.  Adoption of encryption and tokenization technologies to protect sensitive data, including PAN and expiration date, for both card-present and card-not-present environments.  Adoption of cardholder authentication (e.g., 3D Secure) for the card-not-present environment. No silver bullet is available to stop fraud. However, as summarized in Table 12, Table 13 and Figure 29, a layered security strategy that includes EMV, tokenization, and encryption is the right approach for securing payment card transactions.

9 E-purse and Stored Value Cards Electronic purses (e-purses) are available in very different types and forms. All have the common objective of creating electronic cash (e-cash) to free the customer and the merchant from needing to manipulate physical cash for small value purchases. The payment transaction is electronic but instead of having the money come from a debit or credit account, the funds come from an amount of cash the customer has already reserved for such payments. Systems vary based on where the money (or value) is stored and how universal it is (in terms of buying power). Systems also have very different security risks to address (e.g., fraudulent creation of cash, loss of cash, anonymity of users). Electronic purse systems can be classified based on where the cash reserve is held and managed, either on a:  Central server, or  Card Systems can also be classified based on the type of merchant that accepts the electronic purse for purchases.  A closed system will have only one merchant accepting the e-cash (or value) stored in the e-purse  An open system is when all merchants accept the same e-cash payment mode, allowing a consumer to use a single stored value card or e-purse in a variety of locations for a broad range of purchases.99 Closed system stored value cards are also known as prepaid cards. Example implementations of closed system stored value cards include: mass transit fare payment cards, college or corporate campus cards, telephone company prepaid cards.100 This section will discuss four different types of electronic purse implementations:  Open system with central account management of operations  Open system with no central account management of operations  Closed system with semi-offline e-purse usage (e.g., prepaid account with balance in a smart card)  Closed system with online centrally managed accounts (i.e., prepaid online) Table 14 shows examples of open and closed e-purse systems. Table 14. Examples of Open and Closed E-Purse Systems Open E-purse Systems Closed E-Purse Systems  Chipknip, Belgium and  French prepaid telephone cards Netherlands  Hong Kong Octopus Card  Edy, Japan  London Oyster Card  GeldKarte, Germany  Parking e-purses  Mondex  San Francisco Bay Area Clipper  NETS Cash Card, Singapore card  Visa Cash  Store-branded prepaid cards

99 The Electronic Purse, by John Wenninger and David Laster, Federal Reserve Bank of New York, April 1995 100 Ibid.

9.1 Open System with E-cash Value on the Card and Central Account Management An open e-purse system that is able to work in a semi-offline environment and that uses a central account management system includes the following participants, or actors:  Customers (or end users), who have smart cards which contain electronic funds (the e- purse).  Merchants, or service providers, who are equipped with POS terminals able to accept the e-purse smart cards for small value purchase transactions. The terminals accept purchases and deduct the purchase value from the e-purse in the smart card without being online.  The e-purse central account management system, which manages the transactions and the fund pool (the cash which was prepaid by the customers but not yet spent). This fund pool receives hard money (either cash or funds from a credit or debit card) from the customer and transfers an electronic representation of this money into the e-purse in the smart card. This fund also provides payments to the merchants.  Banks. For legal reasons (i.e., laws related to printing, handling and managing money), many countries, including the United States, require banks to be involved in such an open e-purse system, on the customer side, merchant side, or both. In this architecture, all transactions are accounted for (though some systems may aggregate the transactions) and the e-purse account is settled periodically (e.g., once per day, or once per week) by the central system. The smart card acts as if it is a purse containing cash, which can be used anywhere, at any merchant accepting cash (assuming ubiquitous acceptance locations for the e-purse approach). The terminals may send the transactions to the central system in real- time, but they primarily use batch mode (connecting to the central system or using portable memory devices to unload the value). If a card is lost or stolen, the system can quickly block the card use (based on the settlement cycle) and the customer may not lose all of the e-cash stored in the card. According to the system's financial rules, the customer would have the value that was on the card when it was blocked restored to the card. (The settlement process enables the system to know how much money was available on a card after all accepted transactions were settled.) By design, the system does not provide any anonymity for customer purchases and appears to work like a debit card (or a gift card) from the user's stand point (without having to present a PIN for transactions under a certain amount). The main difference from a debit card system is that the funds are first maintained in the card and then verified in the back-end system. The e-purse system also has the ability to work with offline terminals since the card keeps track of the amount of money available in the account. Such a system is primarily suitable for countries (or situations) where online telecommunications are costly or unreliable for low value transactions. E-purse cards may include counters that would force the card to go online at some point for security purposes or to synchronize the balance. The cost of running this type of system can be very expensive if all transactions must be accounted for, since this requires a lot of processing in the back end. The system also requires that the keys are maintained at various levels: in cards to sign the transactions; in the merchant's terminal to authenticate the card. This key management, when done properly, can be an important part of the system's cost of operation. The largest implementation of such a model was done in Denmark (known as the Danmont e- purse) and was phased out in December 2005.

The Comité de Européen Normalisation (CEN) produced a European standard, EN 1546, for inter-sector electronic purse systems. The Danmont e-purse and Austria Quick e-purse were both based on this standard. The international standard, Common Electronic Purse Specification (CEPS)101, was developed by Visa in the early 2000s; essential features of CEPS were based on the EN 1546 standard.102 The CEPS specification has had little adoption around the world as a universal e-purse. Nevertheless, the specification can be used in closed systems (see Sections 9.3 and 9.4) and can be very useful in defining the functional requirements for security application modules (SAMs) protecting the application keys in the terminal. Another commercial e-purse system specification is Proton, published by Proton World. The Belgian and Netherlands Chipknip e-purse and Swiss and Swedish "Cash" e-purses use the Proton specification.103 Figure 30 illustrates an open e-purse architecture.

Figure 30. Open Electronic Purse System Architecture.

9.2 Open System with No Central Account Management An implementation of an open system with no central account management was developed by Mondex (a consortium of companies), using the smart card MULTOS operating system. Based on public key technology, this system architecture allowed each card to authenticate any other card of the system, enabling transfer of electronic money from one card to another without a terminal being involved in any secure operation. In this architecture, the actors are:

101 The CEPS specifications can be found at http://www.irisa.fr/vertecs/Equipe/Rusu/FME02/functionalrequirements6-3.pdf 102 Smart Card Handbook, Wolfgang Rankl and Wolfgang Effing, Fourth Edition, John Wiley and Sons, Ltd., 2010, p. 760 103 Rankl, p. 775

 Customers (or end users), who have smart cards which contain electronic funds (the e- purse).  Merchants, or service providers, who are equipped with a merchant card using the same e-purse as the customers and able to accept the e-purse smart cards for small value purchase transactions. The merchant (or any customer willing to accept cash in payment) needs to also have a terminal that can facilitate communication between two cards in order to exchange cash. In theory, no transaction is used for the settlement, but some implementations allow transactions to be created by terminals for audit and journaling purpose.  The central e-purse system, which only manages the funds pool (i.e., real cash that is converted into e-cash and e-cash that is converted to real currency) and some transaction auditing and reconciliation functions.  Banks. For legal reasons (i.e., laws related to printing, handling and managing money), many countries, including the United States, require banks to be involved on the customer side, merchant side, or both. In some countries, this approach is not even allowed since it could be used to launder money or create false money if the system security is breached. In this model, the merchants are paid directly by the customer's card and are able to use the cash they receive immediately to make payments or to deposit the funds into a bank account. This system has no simple reconciliation of accounts. The system does not know the exact amount of money in a given card since all transactions are not reported. Since the cash in a card is not known, users typically cannot recover the funds when a card is lost or broken. Some countries have expressed concerns about this architecture being used by money laundering organizations. Another major concern is that criminals could determine how to hack cards and add funds into the system; the lack of a simple reconciliation function would make this type of fraud hard to trace.

9.3 Closed System with Semi-Offline Account Management The most widely used application of smart card e-purses around the world is implemented as a closed system with semi-offline account management. This architecture is the same as the open system with e-cash on the card and central account management, but use is limited to a given area, service, or group of merchants and does not involve as many players. (Thus, the term "closed" is used since as the e-cash cannot be used for all services for all merchants.) Initially used by telephone companies for prepaid cards (mainly in France and Germany), many transport systems all around the world are now using this model. The e-cash in the card allows the user to pay for transportation (or parking) related services, or for various services in a given city or on a given campus. In this type of system, one "merchant" provides various services (e.g., parking, subway ride, bus ride) and the prepaid funds cannot be used to purchase services from any provider that is not part of the "closed" system. The generic architecture for this approach is less complex since the need for a financial partner is much more limited. The "money" stored on the cards is not really e-cash, but pre-paid funds for specific services and no more. Another name for the funds could be "local money" (as with a store gift card), which presents more limited fraud risk on many levels. The system does not require reconciliation among merchants and the funds pool is directly administered by the service provider (or its bank if a financial institution involved). From the user's standpoint, the system's behavior is similar to a closed system with centrally managed accounts (described in the next section), as long as transaction processing is fast and reliable. Because the funds in the system are not equivalent to cash, fraud risk is more limited and the system does not provide a high level of return on investment for a hacker. (However, this does not prevent negative reporting if a hacker finds a weak point to attack the system.)

Many systems are built on this model where the card contains an amount of prepaid cash. This approach also allows the system to be able to work in offline, when the network goes down or when infrastructure costs justify offline operation. Examples of closed systems with semi-offline account management include: London Oyster Card, San Francisco Bay Area Clipper card, Hong Kong Octopus Card, French prepaid telephone cards. Figure 31 illustrates a closed e-purse system architecture.

Figure 31. Closed Electronic Purse System Architecture

9.4 Closed System with Online Central Account Management (Prepaid Online) A closed system with online central account management generally does not use smart cards since all of the security is provided by the central system. An example of this type of system is a store gift card. The gift card has a unique number, and when activated, the card provides access to an online account (maintained by the store) which manages the funds that have been prepaid into the account. Another example of this type of system is EZ-Pass, which is used for toll payment throughout the U.S. East Coast. With this type of system, the customer prepays a certain amount of money; this allows the cardholder (who may not be the customer who paid for the account) to buy a given service, up to the amount secured in the account pointed to by the card. When the account is empty, new funds can be deposited in the account or the account holder may have agreed to have automatically refill the account from another type of financial account (e.g., credit card, bank account). This system does not require a lot of card-level security, since all the verifications are made in real-time in the central system. Most systems use non-intelligent cards, such as magnetic stripe cards. The customer assumes most of the risk in this system. If the card is lost or stolen, or if anyone is able to create a counterfeit card pointing to the account, the funds can be used until the customer indicates to the central system that the card number should be blocked.

Debit cards are a variation of this type of scheme, since they are also payment instruments that access a pre-funded account. Debit cards, however, often require customers to enter a PIN to prove that they are the legitimate account holder. Prepaid, closed, centrally-managed e-purses are quite common and are often used by transit authorities for parking or transit fares, or by libraries for copies or Internet access. The cards are often quite simple and have little or no security or some proprietary protection. The fraud risks for this type of system are rather low, since the system is able to verify every transaction at the time it happens. The system will immediately accept or deny the purchase (as with debit or credit payment systems), and will not allow purchases beyond the amount of funds that are deposited in the account.

10 Transportation and Parking Payment

10.1 Transit Mass transit agencies worldwide have been using stored value prepaid cards for electronic ticketing since the 1970s. Through the late 1990s, this market steadily began transitioning from magnetic stripe technology to contactless smart cards. Today, virtually all transit fare payment systems in the delivery and procurement stages use contactless smart cards as the primary ticket medium. Most of these systems use agency-branded contactless smart cards as the primary fare medium and are based on proprietary software. Major deployments are operational in cities around the world, including:  EZ-Link in Singapore  Octopus Card in Hong Kong  Oyster Card in London  RATP Navigo in Paris  Suica in Japan Most major North American metropolitan areas also have either closed-loop, stored value contactless smart card based AFC systems or have migrated or are migrating to an account- based system architecture that supports both open payments and stored value contactless smart cards. Table 15 includes examples of North American transit agencies using contactless smart cards for fare payment. Table 15. Examples of Contactless Smart Card Fare Systems in North America104

U.S. Transit Agency Program Name Atlanta, GA - MARTA Breeze Baltimore, MD - MTA CharmCard Boston, MA - MBTA CharlieCard Chicago, IL – CTA Ventra Card Houston, TX – Metro Q® CARD Lindenwold, NJ – PATCO FREEDOM Card Los Angeles, CA – LA-MTA TAP Card Miami, FL – MDT EASY Card Montreal, Quebec – STM OPUS Card NJ/NY – PATH SmartLink Card Salt Lake City, UT – UTA FAREPAY Card San Francisco, CA – MTC Clipper Card Seattle, WA – KC Metro ORCA Card Toronto, Ontario – Metrolinx PRESTO Card Washington, DC – WMATA SmarTrip Card

104 Source: Survey conducted by Ashok Joshi, KEI; updated with industry information

10.1.1 Traditional Transit Fare Payment Systems105 Traditional transit fare payment systems rely on transit agency issuance of some form of fare media or ticket and operate as closed loop systems. The fare media in an automatic fare collection (AFC) system is typically based on a stored value payment model. The stored value can be represented in different ways: as electronic cash, as a fixed number of rides, or as a period pass. Transit customers prepay a certain amount, which is then stored in an electronic purse (e-purse), either on the fare medium (e.g., a contactless smart card) or in a central account on a host system that communicates with the fare medium. Cash, credit, debit and prepaid payment products are widely accepted in the transit industry for purchasing fare media and for loading stored value on the transit payment cards. Transit patrons now use financial payment cards (either magnetic stripe, EMV chip or contactless cards) to buy transit fare cards from vending machines, customer service agents, and transit web sites. Patrons are issued the transit-specific fare medium, which is then used for a fare payment transaction at the entrance to a subway, bus, or other mode of transportation. Transit stored value instruments are typically valid for fare payment only at the agency issuing the fare media or across localized regional operators holding acceptance agreements with the issuing agency. These multi-agency solutions are facilitated by agreeing on a single standard payment media and service provider, or by promoting a single technical standard to which systems can be built. The traditional transit fare payment system has a proprietary “card-based architecture,” where the fare payment media and card reader make the decision to approve or deny the fare payment transaction (including determining the fare). On-board or in-station equipment reads, interprets, and processes this data to apply fare policies and generate transaction records. Terminals are designed so that the fare payment process can occur offline. Records are stored for forwarding or collection later, supporting consolidation, detailed audit reporting, and security. Networks are designed to leverage intermediate consolidation nodes that facilitate this process and protect against data loss. In a fare payment transaction, the fare value is deducted at the point of entry from the stored value or validity is checked for a fare product (pass, multi-trip ticket, transit benefit). Transit e- purse transactions resemble typical cash transactions with two important differences:  Communication between the local reader and the card at the point of entry completes the transaction. This interaction is generally both a validity check (through the application of rules that apply to the use of the fare media) and, in the case of stored value, an update of the remaining value on the fare media. In some cases, the transaction occurs offline (e.g., on a bus) and a central system is updated later. In other cases, a virtually real-time data exchange is possible. In most cases, however, the transit system validates payment at the time of use of its fare media rather than accumulating charges and billing later.  During the transaction at the point of entry, data elements critical to the transaction (e.g., location identifiers, descriptions of past use) are transmitted to enable payment of the proper fare using applicable rules. To meet the operational requirements of most transit agencies, the transaction must be completed typically in less than 300 ms. In a multi-operator system, clearing functions are either handled in a central system by one of the participating operators or by a third party. Figure 32 illustrates a smart card-based transit payment system architecture incorporating multiple operators, multiple modes and a central clearinghouse. Transaction data is collected and reconciled at the central system, and the correct fare revenue is deposited in the appropriate operator’s account. If external merchants participate in the program, the clearinghouse can also clear funds for the merchants as well.

105 Sources: Smart Card Alliance white papers

Figure 32. Multi-Operator Transit Stored Value Smart Card Payment

10.1.2 Smart Card Use in Public Transit106 This section reviews the use of smart cards in public transit fare collection systems. Examples focus on North American implementations; however, the topics are relevant to transit implementation of smart cards globally.

10.1.2.1 Early Adopters – Contact Smart Cards Several early adopters of smart cards used contact smart cards, as opposed to the contactless cards that are widely used today. Trials in Bus Systems (Early 1990s). In the early 1990s, several trials of ISO/IEC 7816- compliant contact smart cards were conducted. Most of these trials were short-lived, and occurred on bus-only operations. Generally, the trials focused on addressing whether stored value smart card transactions would relieve slow boarding (queuing) and other operational problems seen by bus operators by reducing cash transactions, or by providing an alternative solution to read/write magnetic stripe-based systems. It is believed that few if any of these trials were deployed beyond the trial phase. Vancouver, BC – West Coast Express (1995). The first known contact smart card system that went into full revenue service was for BC Transit’s West Coast Express commuter rail system in 1995. That system used contact smart cards as stored value media with which passengers could purchase plain paper tickets from vending machines. (The tickets were used to demonstrate proof of payment; the smart cards were simply another payment method for the purchase of the tickets.) The smart cards could be reloaded at the same vending machines using cash or credit

106 Content in this section was contributed by Peter Comps and Joshua Martiesian, LTK Engineering Services.

cards. Because the fare policies offered some incentives for using the smart cards, patrons accepted the system. The agency saw a reduction in cash handling, which provided operational benefits in lower servicing and maintenance costs. As a result, the system was deemed a success and remained in service for more than 10 years until the vending machines were replaced, at which time the smart cards were also replaced with contactless cards common to other BC Transit services.

10.1.2.2 First Uses of Proprietary (non-ISO/IEC 14443) Contactless Cards The first implementations of proprietary contactless cards for transit fare payment were introduced in the 1990s. Cubic developed the first contactless smart card for transit and fielded it during the London Touch and Pass trials running from 1989 thru 1991. Based on these developments, the Cubic GoCard was developed and introduced to the Washington Metropolitan Area Transit Authority (WMATA) in Washington, DC, in 1994, as part of the Uniform Fare Technology trial partially funded by the Federal Transportation Administration. Cubic signed full deployment contracts with both WMATA and the Chicago Transit Authority (CTA) in 1997, fully four years prior to the ratification of ISO/IEC 14443 in 2001. Both WMATA and CTA are extensive installations that grew to cover subway and bus operations, with vending machines and other ancillary elements. Both used contactless smart cards as stored value media, as well as various forms of unlimited ride passes.

10.1.2.3 Widespread Adoption of ISO/IEC 14443 Contactless Smart Cards As more suppliers made inroads into the market, the ISO/IEC 14443 standard gained widespread acceptance as the preferred basis for contactless smart card fare systems. Since 2000, every new contactless smart card fare collection system has been based on the ISO/IEC 14443 standard.107

10.1.2.3.1 Card-Based Fare Systems The vast majority of the existing smart card-based fare systems encode information on the card. Information encoded on the card typically includes:  Serial number (also known as the UID)  Card status (not issued, issued, deactivated)  Usage transaction history (typically no more than 10 prior transactions)  Replenishment transaction history  Transfer eligibility (usually based on transaction history)  A stored value purse (as applicable)  Stored ride counter (as applicable)  Unlimited ride pass information (as applicable)  Cardholder profile information, such as fare category (full, reduced), date of birth (used to disable age-eligible reduced fares such as student fares), or employer ID (for subsidized ride programs)  Automatic reloading subscription information  Encryption keys Much of this information is used as part of every transaction, and some information is regularly updated. This process enables the read/write card processors to determine validity of passes, transfer privileges, sufficient value to be deducted, and several other fare policies that can be programmed into the system. Completed transactions are generated at the fare terminal and forwarded to the back office for summary reporting and audit control. While this architecture was necessary given the previous state of network communications, a consequence has been

107 Additional information on the ISO/IEC 14443 standard can be found in the CSCIP Module 1, Smart Card Fundamentals.

complex device-level software which can require significant customization to implement the often unique fare policies of each agency. Recent advances in both fixed and wireless network technologies have opened the door to less distributed processing approaches.

10.1.2.3.2 Commonly Supported Fare Policies Not surprisingly, the existing card-based contactless smart card fare collection systems have successfully implemented virtually every fare policy in use in North American public transit. Implemented policies include:  Stored value  Stored ride  Floating period unlimited ride passes  Fixed period (calendar-based) unlimited ride passes  Embedded transfers  Level-of-service fare structures (e.g., local/express/regional/premium)  Time-of-day (peak/off-peak) fare structures  Holiday/weekend fares  Multi-zone fare structures These policies have been used on all modes of public transit, including bus, light rail, commuter rail, subway, bus rapid transit, streetcar, ferry, and paratransit. The systems using contactless smart cards also include barrier (i.e., pay upon entry or boarding) and barrier-free (i.e., proof of payment) systems. In many cases, a patron’s card will have multiple payment methods simultaneously. For example, a patron’s card may have a 30-day local pass and stored value. With such a card, the patron could begin a trip on a local bus and pay no additional fare due to the valid 30-day pass. Upon transferring to an express bus, the patron would have only the incremental value of the express bus trip deducted from the stored value “purse” on the card. A subsequent transfer to another express bus would be granted without further deductions from stored value, because the patron has already paid for that level of service.

10.1.2.3.3 Fare Media In North America, most of the ISO/IEC 14443-compliant systems have deployed smart cards based on NXP Semiconductors’ MIFARE™ product line for their primary fare media. MIFARE Classic is by far the most common technology, but some systems have deployed DESFire cards because of their improved security. It should be noted that, in spite of the many complex fare policies that modern fare systems must support, to date, virtually every policy has been successfully deployed on a MIFARE Classic 1K card. Outside of North America, MIFARE has been use in transit contactless smart cards, as well other smart card technologies such as Calypso and Sony’s FeliCa. More recently, limited use (disposable) contactless fare media have also become widely used. These media are compatible with the ISO/IEC 14443 standard, and are additionally described by the ANSI INCITS 410-2006 standard108. Contactless limited use cards are ideally suited for one- day and other short-duration passes, as well as other limited use needs. Because of the significantly reduced memory capacity available on the most inexpensive forms of this media, the amount of dynamic data that can be encoded is limited. As a result, these instruments cannot provide the flexibility needed to simultaneously support all varieties of fare policies, so their use is generally limited to a single purpose, such as stored value, stored trip, or short-duration passes. However, like long-duration contactless fare media, data is read and frequently re-encoded on every use. As the name implies, limited use media are designed to satisfy passenger needs over a short time interval, usually no more than 30 days. Because these cards are not designed for

108 http://webstore.ansi.org/RecordDetail.aspx?sku=ANSI+INCITS+410-2006

long life and have limited memory capacity, limited use media are usually not replenished when their value is depleted.

10.1.2.3.4 Encoding For card-based fare collection systems, the format in which the data is encoded on the card is the foundation of the software design. The encoding format drives the procedures and algorithms that govern how the smart card read/write processor conducts transactions, as well as how the data is transmitted to and stored in the central databases that are an integral part of any modern fare collection system. In the late 1990s and early 2000s, contactless smart card systems were being implemented throughout North America, all in the absence of a well-recognized and accepted standard for how data was to be encoded to the cards. Consequently, the suppliers all developed their own proprietary solutions for the data encoding formats, as well as the corresponding embedded software on the smart card read/write processors. These systems have been largely successful in every respect, but proprietary systems tend to limit flexibility and expandability. To address this concern, contracts have included the provision that the intellectual property encompassing the smart card encoding format be made available to the transit agency so that third parties could participate in expansion and enhancement efforts. However, to date, all expansion and enhancement projects have been performed by the incumbent supplier, so the efficacy of the intellectual property provisions has not been demonstrated. Recognizing how intellectual property issues could potentially limit competition and increase costs, the American Public Transportation Association began a concerted effort in the early 2000s to develop a comprehensive standard for smart card-based fare collection systems. This effort, the Common Fare Media Systems (CFMS) standard, is now complete and is a recognized standard. CFMS as a standard is similar in structure and approach to several international transit interoperability standards such as ITSO in the United Kingdom, VDV in Germany, and RKF in Scandinavia. (See Section 10.1.4 for additional information on transit standards.) Because of the myriad of fare policies that full-function smart cards must support, the data encoding format on these cards is complex. (In fact, a full implementation of the CFMS standard requires approximately 2K bytes thus driving current implementations to the MIFARE DESFire 4K, or media with equivalent processing power and data capacity.) In contrast, the limited use media used for short-term fare policies requires significantly less data capacity, usually less than 80 bytes of dynamic data. As such, the most basic limited use cards satisfy transit agency requirements. In addition, the associated data encoding formats are relatively simple and easily shared among suppliers (assuming intellectual property rights are assigned to the transit agency).

10.1.2.3.5 Distribution of Media For any fare collection system to succeed, regardless of the fare media employed, the fare media must be available to the passengers. Because of their relatively high cost (compared to plain paper or magnetic media) and their intended long life, distribution methods for contactless smart cards are designed to optimize convenience to the patron and cost to the agency. Excluding the temporary free distribution that often accompanies the introduction of a new fare system, most contactless smart card fare media are distributed through the following channels:  Over-the-counter point-of-sale  Self-service vending machines  Internet sales and direct mail fulfillment  Employer/institutional (third party)

10.1.2.3.6 Replenishment Taking advantage of the long expected life of the contactless smart card media (and the corresponding economies that incur) requires convenient replenishment methods. Transit agencies have relied on a variety of such methods, usually consisting of one or more of the following:  Over-the-counter point-of-sale  Self-service vending machines  Automatic reloading (also known as “autoloading”) Autoloading is perhaps the most convenient method of replenishing smart fare media value. In general, three distinct varieties are in use. While some variations in implementation exist among suppliers and agencies, these methods are:  One-time (directed). With this method, a patron visits a web site and enters the serial number of their card, the product or value they wish to purchase, and payment information. When payment is authorized, the central data system will notify all, or specifically identified groups, of the smart card read/write processors that the patron’s card (identified by unique serial number) has a pending autoload transaction of the type and value purchased. (The pending autoload information also includes a unique transaction number.) When the patron presents their card to a device with the pending autoload information, the read/write processor will encode the patron’s card with the purchased product or value. Other processes within the system prevent duplicating the autoload transaction. These transactions can be anonymous in that the patron need not register their card with the agency prior to conducting the transaction. (See registration discussion below.)  Subscription (threshold). Unlike the one-time directed autoload, subscription autoloads can occur multiple times after a single “set-up” procedure. These autoloads are invoked when the value of the patron’s card passes a pre-set threshold (which can either be a remaining stored value or trip) or the expiration of an unlimited-ride pass. The autoload acts like a subscription and is set up accordingly. For example, if the card’s value falls below $10, add $40, or if the patron’s 30-day floating pass has expired, automatically renew and activate the new pass. Patrons must first “subscribe” to these autoloads by establishing the desired threshold, the action to take when the threshold is met (product or value to add), and the method of payment. This setup process usually occurs on a web site, although it can also be performed at point-of-sale devices. When the setup is performed on a web site, once the subscription information is defined and the payment method is authorized, the central data system will transmit the subscription data (via a specialized directed autoload) to be encoded to the patron’s card when it is next presented to a read/write device. (If the setup occurs at a point-of-sale device, the device will encode the subscription information at that time.) Once the subscription information is set up on the patron’s card, the autoloads occur without further intervention by the passenger. The system will automatically process the payment transactions whenever the central data system is notified that the threshold autoload occurred. Because of their repetitive nature and the need to maintain current payment information, these autoloads are generally available to patrons who register (i.e., identify themselves) with the agency. (See Section 10.1.2.3.7 below.)  Periodic (calendar). These autoloads are similar to subscription/threshold autoloads in that they are repetitive and are based on information encoded on the patron’s card. However, rather than being triggered at any time by a threshold event, these autoloads

occur on a regular, periodic basis, most commonly every calendar month. In most cases, these autoloads are designed to satisfy the requirements of employer-sponsored transit benefits programs. Such programs are restricted by Federal tax law to being limited to a certain value per month. Cards with periodic/calendar autoloads are generally registered with the agency.

10.1.2.3.7 Registration and Replacement One of the more popular features offered by modern smart card-based fare collection systems is the ability to replace a patron’s card in the event it is lost or stolen. To do so, the patron registers their card (by serial number) with the agency, and provides some method to verify identity, such as a PIN or a secret question. When a lost card is replaced (with the original card’s residual value, usually less some modest administrative fee), the original card’s serial number is placed on a “bad card” list that is broadcast to all read/write devices. If the lost card is subsequently presented to a read/write device, the device will permanently disable the card by encoding the card with a “deactivated” status. Thereafter, the deactivated card’s serial number can be deleted from the list of “bad cards” that is broadcast. (However, the central data system will retain the record that the card was deactivated.)

10.1.2.3.8 Equipment Contactless smart card fare collection systems employ a wide variety of specialized equipment. In addition to a centralized data system, which is universal to all modern fare collection systems, the smart card systems include one or more of the following devices:  Bus validators – used on fixed-route bus systems for patrons who pay upon boarding  Platform validators – used on commuter rail, light rail, and bus rapid transit platforms where barrier-free (proof of payment) fare collection is employed  Fare gates and turnstiles – used where barrier fare collection is employed, typically on subway or grade-separated rail systems and some ferry terminals  Self-service vending machines – used by any mode of fare collection where self-service convenience is provided  Point-of-sale terminals – typically used as a distribution and replenishment method at third party retail outlets, but also at agency-operated customer service venues  Portable handheld readers/validators – usually used by fare inspectors for proof of payment fare systems  Bulk encoding machines – used to provide low to high volume bulk encoding, typically to support institutional media distributional needs  Personalization encoder-printers – often used to create photo ID or corporate ID cards that are encoded upon personalization

10.1.2.4 Emerging Trends Technological advances are bringing an evolutionary change to contactless smart card fare systems. As data communications capabilities expand along with central data system computing power, smart card fare systems have begun to move away from card-based systems to centralized, account-based systems.

10.1.2.4.1 Account-Based Systems The most fundamental technical difference between card-based and account-based systems is where the transaction is processed. In card-based systems, the transaction is fully processed at the read/write device, and the central data system is merely informed of and records the transaction’s details. In an account-based system, the transaction at the device is generally read- only and the smart card is treated as simply a credential that is tied to an account at the central

data system. The device reads the card’s token or identifier, performs localized risk management (which is complemented by risk management processes on the account-based processing engine at the central data system), and reports information about where and when the card was read to the central data system. The central data system will then process the data to determine the value of the transaction and what additional steps may be required (such as initiating a payment transaction). In systems based on traditional smart cards, the smart card is identified by a token or identifier. Systems accepting contactless bank cards and devices (e.g., mobile phones) may use the cardholder’s primary account number or other identifying token, while identification cards may be identified by the cardholder’s ID number. In essence, each patron’s card in an account-based system represents a link to a pre-established (or dynamically-established) account. In the U.S., the Utah Transit Authority (UTA) and Chicago Transit Authority (CTA) have fully deployed account-based systems for fare collection. The Southeastern Pennsylvania Transportation Authority (SEPTA) and Washington Metropolitan Area Transit Authority (WMATA) are currently in the process of implementing account-based systems for their new fare collection initiatives.

10.1.2.4.1.1 Fare Media Account-based systems can use any ISO/IEC 14443-compliant smart card that provides an identifier or token that can be authenticated. These cards can be issued by the agency or third parties (with which the agency has pre-established interfaces).

10.1.2.4.1.2 Intellectual Property Because the transactions are generally read-only, systems integrators can use the tools provided for the most widely used ISO/IEC 14443-compliant cards and create a secure token or identifier that can be used by account-based systems. In some cases, agency-issued cards may have some user profile data encoded, such as eligibility for reduced fares (for example, to enable a bus driver to verify that the cardholder is eligible for the reduced fare), as well as a card status “flag” to permanently disable cards that are on the “bad card” list. Where third party-issued cards are used, the agency is generally prohibited from writing to the card. A reduction in intellectual property offers the potential for benefits by simplifying the implementation of solutions from more than one supplier and supporting a more competitive procurement environment.

10.1.2.4.1.3 Authorization Methods Passenger throughput is often a primary concern when designing a fare collection system. Fare collection transaction speeds are therefore an important consideration when designing these systems.  Offline. In account-based systems where all of the cards are issued by the agency (often called “closed” systems), cards may be authorized with the readers operating in standalone (offline) mode. If the agency-issued card contains some custom-encoded data to enable the reader to identify it as legitimate, approval can occur by comparing each presented card’s serial number against lists of either known “good” or “bad” cards. However, in most systems performing offline authorization, no such custom encoding resides on the card. (In addition, agencies are usually constrained from writing any data to cards issued by third parties.) In this case, instead of checking each presented card against a list of “bad” cards, most offline authorization schemes compare the presented card’s identifier against a list of “good” cards. This prevents the system from accepting

known “bad” cards (which are simply left off the list) as well as cards that are not part of the system (i.e., cards that were not issued by the agency or a participating third party). Even with “good card” lists containing more than 250,000 entries (which is enough to satisfy the vast majority of transit agency needs), modern smart card readers can perform transactions well within the required speed for transit applications.  Online. Where real-time (or near real-time) data communications are available, the card readers in account-based systems can check the token or identifier from a presented card and request the central data system to perform the authorization check, again using lists of known “bad” and “good” cards. Many systems may also use a transit agency’s list of known “bad” cards locally at the card reader for those instances where communications are temporarily unavailable.

10.1.2.4.1.4 Communications Infrastructure Requirements Communications requirements for account-based offline systems are similar to those of standard card-based systems. Each reader’s internal lists are updated on a regular basis, usually a full update at least daily with potential incremental updates during the day, and transaction records are uploaded to the central computer system no less than once per day. These periodic updates can occur via dedicated networks (such as those serving rail stations), and when vehicles enter maintenance facilities, typically via standard IEEE 802.11 Wi-Fi networks. With offline systems, there can be a higher incidence of fraud unless the card has an authentication token that allows the reader to validate the card’s authenticity. Account-based systems that perform online authorization require more robust data communications networks. While data networks from rail stations and bus facilities to central data systems are frequently fixed assets under control of the agency, mobile data infrastructure is often based on mobile phone technology.

10.1.2.4.1.5 Account Management By its nature, the central computer system is the nexus of any account-based system. The central computer must track all accounts, and all transaction records must be processed so that the effect of valid transactions on each account’s value can be calculated. To provide the necessary flexibility, several types of accounts must be managed:  Pay-as-you-go. A customer who rides infrequently may wish to establish an account where they are charged on a ride-by-ride basis by linking their smart card account to a payment method of choice, such as a credit card or a bank account. Prior to completing the registration process, the central computer will verify that the payment method is legitimate. Then, as the transaction records are reported for each ride taken, the central computer will compute the value of each ride based on the agency’s fare policies. To minimize transaction fees, the central computer system will accumulate a balance in the customer’s account until it exceeds a threshold value, some time limit is reached, or a quantity of rides threshold is exceeded. At that time, the central computer will initiate a payment transaction according to the customer’s selected payment method. As an incentive to passengers who use pay-as-you-go more frequently, the central computer system can track a patron’s usage and determine if the patron would have benefited by purchasing an unlimited ride pass. If so, the central computer system can forego charging the patron’s account once the account has accumulated individual ride fares within a time period (such as the last 30 days) that would have equated to the purchase price of an equivalent time-based pass.  Prepaid accounts – Individuals. In account-based systems, customers may also pre- purchase fares by paying in advance for individual rides (equivalent to a stored-value card) or for unlimited rides for a number of days (equivalent to a floating period pass). As

long as the account has remaining value or an unexpired pass, the passenger will be able to ride. Cash. Using over-the-counter point-of-sale devices or self-service vending equipment, cash-paying customers can pre-purchase fares (stored value or unlimited ride passes) and remain completely anonymous. In addition, this method of account replenishment enables the unbanked and the under-banked to enjoy the benefits of the prepaid account, since no banking relationship is required. Credit/Debit. Via the Internet, point-of-sale terminals, or self-service vending machines, customers can replenish their prepaid account and purchase stored value or unlimited ride passes.  Employer/Institutional accounts. Employers and institutions that provide transit benefits will usually enter into long-term contracts with the agency. These contracts can provide for prepaid transit (such as via an annual pass), post-billed transit (where the value of rides are accumulated and the company is invoiced, usually at a volume discount), as well as several other variations. In most cases, cards used by participating employees are simply read as a credential.

10.1.2.4.1.6 Fraud Detection, Prevention and Tolerance Factors that can determine the architecture of an account-based system are the extent of potential fraud, and the amount of fraud the agency can tolerate. Both offline and online authorization methods are vulnerable to some fraud, largely depending on how diligently the agency maintains the lists of good and bad cards. In both cases, the reliability and dependability of the communications infrastructure can also determine the amount of potential fraud. In general, the more frequently the good and bad card lists are updated, the better, whether those lists reside on the devices or are only on the central computer. If communications are unreliable, offline devices will not receive updates in a timely manner, and online devices will be unable to conduct timely authorizations. Because online authorization frequently requires mobile data networks for the mobile devices, the cost to implement on-line authorization must be balanced against the cost of the fraud that would be saved. Pay-as-you-go accounts are subject to the linked payment methods becoming invalid, so it is prudent to regularly verify account validity, even if there is no activity. Similarly, prepaid accounts can be “overdrawn,” so it is prudent to implement policies that protect against excessive losses.

10.1.2.4.1.7 Supported System Characteristics Account-based systems are agnostic to the type of fare media used. Because these systems rely almost exclusively on reading a token or identifier from a card, many ISO/IEC 14443 cards can be tied to accounts that are tracked in the central computer. As a result, account-based systems can support architectures that are closed (agency-issued media only), open (third party-issued only), and hybrid (both agency- and third party- issued media).

10.1.2.4.2 Combined Systems (Card-Based and Account-Based) While the trends suggest that new contactless smart card fare systems will likely tend toward account-based architectures, many existing card-based systems are evolving to incorporate account-based features. The two architectures are not mutually exclusive. For example, in the early 2000s, CTA had a card-based fare system using stored value cards for bus and rail trips. These cards were replenished at self-service vending machines (and eventually online with autoloads). Several years later, CTA introduced an account-based card that patrons could link to a credit card and use as a prepaid stored value account or as a prepaid

30-day pass, both with automatic replenishment. Both the original card-based cards (the “Chicago Card” and the account-based cards (the “Chicago Card Plus”) coexisted in the system.109 Another example is when special needs arise in a card-based system where an account-based solution is the best fit. Several agencies with card-based systems are finding that large institutional customers, especially local universities, are distributing ID cards that are ISO/IEC 14443 compliant. In these cases, it has been a straightforward exercise to implement “good card” lists of the cards distributed by those institutions and quickly establish an account- based solution to accept those cards for fare payment. In other cases, employers have accepted new ISO/IEC 14443 cards, personalized by the agency’s bulk encoder/printer equipment, as new employee IDs that double as prepaid transit cards. These cards are ostensibly read-only cards valid for a year; each usage is tracked by the central computer so that the following year’s contract price can be based on the previous year’s ridership. Finally, there are instances where account-based systems require some card-based solutions. Transit agencies serve a broad demographic of customers, some of whom rely heavily on social service agencies. These agencies distribute free transit passes, often in single- or round-trip increments. It often makes little sense to create separate accounts for every single-trip card distributed to these social service agencies. Instead, single-trip or two-trip stored trip cards, encoded on limited use media, have proven to be the best solution. Similarly, agencies often wish to cater to the convention and tourism industries by providing targeted fare media and policies such as three-day visitor passes (distributed by hotels and major tourist attractions) or special convention passes (distributed by the convention center, often by mail to participants well in advance of the convention). Pre-encoded limited use media can be a more effective solution for these needs than an anonymous account that is established for each card.

10.1.3 Transit and Open Contactless Bank Card Payment While the transit industry was investing in smart card-based AFC systems, parallel developments were taking place in the financial industry: the introduction of contactless credit, debit and prepaid payment products; new programs and rules for low value transactions; and processing approaches that can handle micropayments cost effectively. Both of these industries also settled on the common ISO/IEC 14443 standard defining the card/reader interface. These developments created opportunities for transit agencies to directly accept contactless bank cards for fare payment at the point of entry where the fare media is ordinarily presented. The following model describes one approach for transit implementation of open payment systems:  Riders use contactless credit, debit, and prepaid cards and devices to pay for fares directly at the point of entry to the transit system (e.g., at the subway gate, on the bus, on a train), and, with some agencies, for parking fees.  The contactless card or device is read at the point of entry and the transaction is routed to the transit agency’s account-based back office system, where the fare is calculated, the transaction is authorized through the financial processing network, and the rider's account is managed.  The transit agency maintains the traditional merchant-acquirer-issuing bank business relationship.

109 Note that CTA has replaced the Chicago Card with the Ventra Card.

 All contactless credit, debit, and prepaid transit fare payment transactions may be processed through the standard operating infrastructure of the financial payments system and use the standard financial industry processes for clearing and settlement. An open contactless bank card approach for transit uses an account-based architecture, rather than the traditional card-based architecture. As described in Section 10.1.2.4.1, a system using an account-based architecture, the terminal110 reads information stored on a contactless smart card and sends it to a back office over a communications network. The back office system (or host) maintains the system’s logic, determines whether the card is valid, and returns a signal that enables the terminal to open the gate or to signal the rider and the bus operator whether to allow passage. The terminal may perform security functions, for example, checking a hot list or positive (cold) list to determine card validity before sending any payment data to the host. The card is typically only accessed with a read function by the terminal. The back office system uses the data sent by the terminal to apply the relevant business rules and determine a price for the transaction using the agency’s fare policy/rules. Transaction types and payment methods can vary with this architecture based on the transit agency’s business rules and the types of technologies deployed. Account-based architectures enable transit agencies to incorporate any contactless smart card into their system as fare media by linking the card to a funding account. The card can be any card, including cards issued by the Federal government, corporations, or universities. An account-based architecture also enables easier changes to fare policy; changes are made in the back office system. Neither the cards nor the terminals need to change. Overall, account-based architectures deliver value to transit agencies beyond simply enabling acceptance of contactless credit, debit and prepaid cards.

10.1.3.1 Benefits of Open Payments for Transit The combination of contactless bank card acceptance and changes to architectures and processes to support contactless payments acceptance at entry/exit points offers a number of potential benefits to transit agencies, including:  Improved flexibility for making changes to fare policy.  Interagency interoperability, with other agencies implementing open bank card payments.  Flexible implementation of government and pretax benefits that are offered on contactless prepaid cards.  Flexible use of ID and other access media for fare payment.  Reduced payment media issuance, avoiding the significant costs associated with ticket issuance and with card lifecycle management.  Improved customer service and a more positive customer experience  Opportunities for partnerships, co-promotion and new revenue streams.

10.1.3.2 Considerations in Implementing Open Payments for Transit Direct acceptance of open contactless bank cards for fare payment at the point of entry/exit is a new approach that transit agencies are starting to move toward. As early adopters implement systems (see Section 10.1.3.3), the transit industry is addressing challenges with implementing a new payments approach. Key considerations include:  Adopting a payment processing model that can accommodate transit’s need for fast transaction times, while managing risk. The bank card and transit industries have

110 The “terminal” is defined as the fare acceptance device at a gate or on a bus. Terminals are also often referred to as electronic readers or validators.

identified a combination of technical and business risk sharing solutions that can assure transit agencies can accept open bank card payments with acceptable risk, including: real-time card authentication with full authorization after the first transaction; transaction aggregation; and other real-time risk management approaches. It is expected as that open payments systems are implemented and become more mature, these solutions will evolve to meet the needs of all stakeholders.  Developing approaches, such as transaction aggregation and prefunded accounts, to reduce transaction processing fees.  Managing a variety of external partners.  Using NFC-enabled devices for the inspection process.  Leveraging branded prepaid cards and/or agency-issued closed loop media for unbanked or underbanked riders.  Working with local card issuers to assess how many contactless bank cards have been issued in their service areas, develop a migration plan that accommodates these cardholders, and offer other fare payment options to riders who do not have contactless bank cards (e.g., contactless network-branded prepaid cards or transit-specific fare payment cards). Additional information on the benefits and challenges of implementing open payments can be found in the Smart Card Alliance white paper, Transit and Contactless Open Payments: An Emerging Approach for Fare Collection.111

10.1.3.3 Transit Industry Migration to Open Payments The transit industry is just starting to migrate to acceptance of open contactless bank cards for fare payment, with U.S. transit agencies currently leading the way. Two U.S. transit agencies, the Utah Transit Authority (UTA) and Chicago Transit Authority (CTA) have fully operational fare collection systems that accept open contactless bank cards at the point of entry/exit to their transit system. Four U.S. transit agencies have conducted conducting pilots to test acceptance of contactless credit and debit cards at the point of entry to the transit system (i.e., at the subway gate and on the bus).  MTA New York City Transit partnered with MasterCard and Citibank in a successful Phase 1 pilot accepting MasterCard PayPass credit and debit payment at subway turnstiles in 2006. The trial produced good results for NYC Transit. The overall feedback from riders was very positive, with the approach easily understood and used. NYC Transit found that the system was highly reliable, accurate and effective and had proven direct cost savings. There were no unanticipated technical issues and transaction speeds were found to be satisfactory. In addition, the Phase 1 average fare increased 17 percent and ridership increased 8 to 13% in both revenues and ridership. The Phase 2 pilot ran from June 2010 through November 2010 and was the first system to replace the need for riders to carry specific fare cards for the three separate transit systems – NYC Transit, NJ TRANSIT and PATH. Commuters transferring between the partner agencies only needed one type of payment device, improving the overall customer experience through increased speed and convenience. The three agencies coordinated linkages between their systems in the Phase 2 trial, such as NJ TRANSIT bus routes that provide feeder service to the PATH system.

111 Transit and Contactless Open Payments: An Emerging Approach for Fare Collection, Smart Card Alliance Transportation Council white paper, November 2011

All MTA objectives were met for the pilots, which were intended as proofs-of-concept to examine the general technical viability of open payments in the transit environment. The operational requirements for speed and real-time authentication were measured and validated. The potential to utilize wireless communications to complement the wired subway infrastructure in a manner that was transparent to customers and agencies was successfully demonstrated. Customers were able to use standard contactless payment cards from issuers around the world at the turnstiles, gates, and fare boxes. Agencies were able to validate the use of comprehensive fare policies, from stored value and transfers to time-based unlimited ride passes and reduced fares. The solution provided a high degree of data security while allowing for significant business and technical flexibility. Finally, customers could conveniently and seamlessly use common fare media across multiple modes and agencies while also having access to a comprehensive suite of customer support functions. The MTA continues to plan towards implementing a new fare payment system for NYC Transit that utilizes open standard contactless payment cards and other ISO/IEC 14443 media, such as identification cards and mobile phones. The MTA continues to progress plans for a new contactless open payments system.  New Jersey Transit. After the conclusion of the joint pilot with NYC Transit and PATH (see above), NJ TRANSIT continued the Tap>Ride program to further test the acceptance of contactless payments on its system. The initial rollout enabled customers to tap and ride with contactless bank cards at Newark Liberty International Airport Station and on three flat-fare bus routes in Hudson County (route numbers 6, 80 and 87). In August 2011, the program expanded to include three multi-zone bus routes (route numbers 43, 81 and 120), including intra-state and inter-state travel into New York with payments based on distance traveled. Customers now have the ability to pay for fares on twice as many bus routes with a simple tap of their contactless credit, debit, prepaid card, mobile phone or device. In addition, NJ TRANSIT became the first transit agency in the world to partner with Google Wallet to test NFC mobile payments, allowing customers to pay with a simple tap of their mobile phone. NJ TRANSIT is testing this technology on ticket vending machines and at ticket windows at New York Penn Station, on the six Tap>Ride bus routes, and at Newark AirTrain Station.  Los Angeles (LACMTA) conducted a 12-month pilot with Visa to offer a co-branded, dual-application contactless prepaid card that can be used both for transit payment and as a general purpose retail payment card.112  Philadelphia/New Jersey region. PATCO piloted the Wave-and-Pay ANYWHERE Visa Prepaid Card, a contactless prepaid card that can be used to pay PATCO fares. Two major North American transit agencies are now migrating to open contactless bank card payments and have either made contract awards or are in the procurement process.  Philadelphia. The Southeastern Pennsylvania Transportation Authority (SEPTA) is now implementing their New Payment Technology Project,113 which will offer riders a variety of innovative payment choices. The project leverages both wired and wireless communication technologies to create a modern fare payment processing system. Patrons will present either interbank or non-bank contactless fare media (passes, prepaid cards, debit cards, and credit cards) to an electronic processor at the point of entry. The processor transmits the payment information over a network to a backend database for verification. The electronic processor complies with banking industry standards, allowing passengers to use any bank-approved payment device or card for fare payment.

112 Visa TAP Co-Branded Card, Jane Matsumoto, LACMTA, presentation, 2009 Payments Councils Summit, February 24, 2009 113 http://www.septa.org/fares/npt/

 Washington, DC. WMATA is now implementing its new fare collection system. Under the New Electronic Payments Program, the initiative is designed to move the agency from an issuer of proprietary, agency-specific fare media to a processor of fare payments directly at the gate or managed through central accounts; this initiative changes the customer experience and offers a wide variety of payment forms accepted by the agency. The media accepted will include bank-issued payment media, agency-issued closed loop media, and the Federal government-issued Personal Identity Verification (PIV) cards and Common Access Cards (CAC) that are in common use in the operating area. Transport for London also accepts open contactless bank card payments for pay as you go travel across the bus, Tube, Docklands Light Railway (DLR), tram and London Overground network.114 The move to open payments also allows transit agencies to position themselves to accept NFC- enabled mobile contactless payments as they are introduced in the market. Essential to success of mobile contactless payments will be a customer experience that meets the transaction speeds critical for the transit industry. (See Section 10.1.5.2 for additional information on NFC applications in transit.)

10.1.4 Transit Standards, Specifications and Guidelines115 Over the last decade, there has been much development, particularly in Europe, of national standards covering traditional closed-loop card-based automated fare collection (AFC) systems. These systems were highly proprietary, therefore in nations such as the United Kingdom, France, Germany, and other EU nations where public transit is highly interconnected and densely used, there was a perceived need for national standards to address this proprietary nature. Well-known examples of these national standards are Integrated Transport Smartcard Organisation (ITSO) in the UK, Verband Deutscher Verkehrsunternehmen (VDV) in Germany, and Calypso in France. Development paths varied from development led by national government (e.g., ITSO) to expansion of a “de facto” standard developed by an operator (e.g., Calypso). The specifications are highly prescriptive, must be licensed, and have organizations that administer to the certification, conformance testing, registration, licensing, membership, and other administrative areas of the use of the standards (for example, ITSO (http://www.itso.org.uk/) and VDV (http://www.vdv.de/en/index.html)). At the international level, the European Committee for Standardization (CEN) engaged the International Organization for Standardization (ISO) and led the development of ISO/IEC 24014-1 Interoperable Fare Management Systems- Part 1: Architecture (known as IFMS) in 2007. The ISO/IEC 24014 standard is decidedly non-technical. Rather it identifies a system architecture and delineates public transport fare collection use cases and some high-level business rules with the goal of providing a sort of reference architecture that allows the various national standards to fit within it without prescribing a specification for those national standards to meet. To date, ISO/IEC 24014 has not been updated; however two new parts are poised for publication that will affect the need to update the standard. Part 2 will be entitled “Interoperable Fare Management Systems- Part 2: Supplemental Concepts to Part 1 for Business Practices.” Part 3 will be entitled “Interoperable fare management system – Part 3: Complementary Concepts to Part 1 for Multi-Application Media.” Both documents are technical reports rather than specifications and provide guidance on business rule implications of ISO/IEC 24014-1. Further, the reports (in the case of part 2) discuss considerations of how an interoperable fare management system can operate in a multi-application environment that includes alternative payment applications beyond the traditional, card-based, closed loop public transport ticketing application covered by ISO/IEC 24014-1.

114 http://www.tfl.gov.uk/fares-and-payments/contactless/how-to-use-it 115 Content in this section was contributed by Timothy Weisenberger, U.S. Department of Transportation/Volpe Center.

10.1.4.1 Transit Standardization and Specification Initiatives As discussed above, transit industry associations and private organizations have defined and published transit-specific application-level and intersystem messaging standards, specifications and guidelines to make distributed regional system architectures easier to design, procure, implement and operate. These include: - The American Public Transportation Association (APTA) Contactless Fare Media System (CFMS)116 standard in the U.S. The CFMS standard defines the data elements and their on-card organization as well as the messages sent between operator-specific systems and the regional processing center; this effort is one piece of the full standards development process to ensure interoperability of systems. - The ITSO standard117 in the United Kingdom; - The Electronic Fare Management (EFM) standard118 defined by the Verband Deutscher Verkehrsunternehmen (Association of German Transport Undertakings – VDV) in Germany. The VDV Core Application system development began in 2003 and has started to be implemented in various projects to varying levels of complexity. The Germany-wide back-office solution for VDV Core Application is under development. It was estimated that 5 million cards would be in the market by 2011 and by 2015 it was forecast that 10 million cards will be in the market in 30 regions.119 - The Scandinavian standard, RKF, which was developed to facilitate one travel card in Denmark, Norway and Sweden.120 The standard is being implemented in various regions of Denmark and Sweden. The standard has yet to be developed to permit interoperability between regions. - The Calypso specification,121 a privately owned European specification that is available for license to industrial partners. Calypso describes the transaction between a contactless card and reader and offers a standardized approach that is supplier- independent. - In Europe, several previously disparate standards, such as ITSO, VDV, and Calypso (France), are being harmonized under IOPTA. This move to standardization is also reflected by national smart card programs currently in the design stages in countries such as the Netherlands, Denmark, and Germany. - The CIPURSE™ specification,122 an open specification that provides an advanced technical foundation for developing highly secure, interoperable, and flexible transit fare collection solutions. CIPURSE was created by The Open Standard for Public Transit (OSPT™) Alliance, an international association chartered to define a new open technology standard for secure public transit fare collection solutions. In addition, transit agencies are now beginning to move to account-based systems using open contactless bank card payments for fare payment to leverage the financial industry contactless payment standards and programs. This move will also position transit to accept payments from NFC-enabled mobile phones. Additional information on open payments and NFC in transit can be found in Sections 10.1.3 and 10.1.5.2, respectively.

116 Additional information is available on the APTA web site at http://www.aptastandards.com/. 117 Additional information is available on the ITSO web site at http://www.itso.org.uk/. 118 Additional information is available on the VDV web site at http://www.vdv.de/en/index.html. 119 Source: Cubic 120 Smartcard Interoperability Issues for the Transit Industry, Transit Cooperative Research Program, TCRP Report 115, 2006, http://onlinepubs.trb.org/onlinepubs/tcrp/tcrp_rpt_115.pdf 121 http://www.calypsonet-asso.org/index.php 122 Additional information is available on the OSPT web site at http://www.osptalliance.org.

10.1.5 Developments in Transit Payment123

10.1.5.1 Transit Extensions to Retail Payment Transit agencies in a number of countries have also extended the use of the transit-issued e- purse for payment at the traditional retail point-of-sale, including the Hong Kong Octopus Card, Korea Smart Card Company Ltd (KSCC) T-money card, Japan Suica card, and Singapore Symphony for e-Payment (SeP).  Hong Kong Octopus Card. The Octopus card was launched in 1997 as an electronic purse for public transportation in Hong Kong. The card’s acceptance and popularity have since extended its use to retailers for general retail payment. This contactless smart card system currently includes over 4,000 service providers, including public transportation services, apparel stores, bakeries, car parks, cinemas, convenience stores, fast food chains, household stores, leisure facilities, personal care stores, photo finishing stores, photocopiers, supermarkets, and vending machines. Octopus cards are also used on school campuses and at residential and office facilities for building access control.124  KSCC T-money card.125 The T-Money card is used for rail, bus and taxi service, parking and retail payment (convenience stores, museums, interior malls, payment of city fines, tax payments, and civil services). Over 10 million unique users generate approximately 25 million daily transactions. 60% of users carry a bank-issued credit card that includes a "light" version of the T-Money application. KSCC has begun to introduce mobile payment in collaboration with three mobile network operators, with just over 300,000 T-Money- enabled phones now. The phones are specially fitted with an antenna and a SIM loaded with the application. These units are not compliant with Near Field Communication (NFC) standards but functionally perform the same way.  Japan Suica card.126 JR East launched the Suica card in 2001 as part of an effort to decrease congestion by improving service and speeding ticket purchase and processing through the faregates. Over 25 million cards and 1 million Suica-enabled mobile phones are in circulation and are used at over 140,000 terminals. The Suica card is used for rail fare payment and, starting in 2004, for retail payment at shopping malls, convenience stores and airport merchants. Of the approximately 20 million transactions on Suica cards per day, 1.15 million are non-transit e-Money transactions.  Singapore SeP.127 SeP is the backend processing, security and clearing system developed by the Singapore Land Transport Authority (LTA) for transit and non-transit payments supporting the Singapore standard for Contactless ePurse Application (CEPAS).128 SeP will allow any card to be used for payment purposes, as long as it complies with CEPAS. CEPAS enables Singaporean issuers to offer a single multi- purpose stored value card for all micro-payments, including transit, taxi, road tolls, parking, and retail. CEPAS-compliant EZ-Link cards have been available for sale since December 2008.

123 Sources: Smart Card Alliance white papers 124 http://www.octopuscards.com/consumer/payment/use/en/index.jsp 125 APTA Trade Mission-Asia Smart Card Tour, David deKozan, Cubic 126 Ibid. 127 Sources: Cubic; http://en.wikipedia.org/wiki/CEPAS; EZ-Link Pte Ltd (2008-12-26). Commencement of sale of the NEW CEPAS-Compliant EZ-Link card, http://www.ezlink.com.sg/NEWS_ez_press26Dec08.htm; 128 Evolution of E-payments in Public Transport--Singapore's Experience, Silvester Prakasam, LTA, Journeys, Nov. 2009

10.1.5.2 NFC and Transit Many transit agencies have deployed wireless or mobile applications by supplementing conventional radio systems with a range of new applications, such as automated stop announcements, automatic vehicle location, and automated passenger counters. NFC technology builds upon these capabilities to provide personalized services for real-time information access and to offer additional capabilities for payment and ticketing. Several successful trials have revealed that passengers want to be able to pay transit fares with a mobile device. Ticketing and payment are applications that are well suited to NFC technology. By touching a phone on a bus fare box or NFC turnstile, the passenger could either process a virtual card resident in their phone or initiate an authentication process with a back-office server that can be configured to charge a flat or distance-based fare. This section describes three different NFC applications that can benefit transit:  NFC-enabled bank card payment for transit fares  NFC-enabled closed system transit ticketing and payment  NFC-enabled transit information applications Additional information on NFC technology, standards and applications can be found in Module 1 and Module 4. A detailed discussion of mobile and NFC applications in transit can be found in the Smart Card Alliance white paper, NFC and Transit, available at http://www.smartcardalliance.org.129 NFC-Enabled Open System for Transit Ticketing and Payment One of the significant benefits to transit operators of supporting a fare collection system that accepts open contactless bank cards (see Section 10.1.3) is that other payment technologies compatible with ISO/IEC 14443 can easily be integrated into the system. A transaction processing model that supports contactless bank cards will support those same applications to the same extent, using NFC-based card emulation. While basic integration for a payment transaction is relatively simple, NFC-enabled devices can support richer interactive user experiences than can a card, providing the consumer with both greater control and greater flexibility. NFC-enabled applications can deliver robust capabilities in the three primary stages of the consumer fare payment life cycle:  Fare product acquisition -- purchasing or topping-up fares.  System entry and exit, and transaction processing – using the NFC-enabled mobile phone and open contactless bank card application for fare payment directly at the point of entry/exit to the transit system.  Post-purchase inspection and processing -- providing passengers with current balance or recent ride history and supporting revenue inspection. For open contactless bank card payment, the NFC-enabled mobile phone can act just as a contactless bank card for paying transit fares or can interact with other mobile transit applications to support other functions.

10.1.5.2.1 NFC-Enabled Closed System Transit Ticketing and Payment NFC-enabled systems make it possible for passengers to buy new tickets, top up tickets, check maps, and check timetables using an NFC-enabled mobile phone. An NFC-enabled phone provides passengers with alternative means of acquiring a traditional closed system transit ticket conveniently over-the-air. In this application, the following functions can be supported:

129 NFC and Transit, Smart Card Alliance Transportation Council white paper, February 2012, http://www.smartcardalliance.org.

 Fare product acquisition – purchasing or topping-up fares. Passengers can use NFC- enabled phones to connect to an NFC-enabled kiosk and download a fare product, or a fare product can be sent directly to their NFC-enabled phone over-the-air (OTA).  System entry and exit, and transaction processing. After the fare product is successfully downloaded to the NFC phone, tapping the phone to a reader validates the ticket and permits access to the transportation system.  Payment validation – providing passengers with current balance or recent ride history and supporting revenue inspection.

10.1.5.2.2 NFC-Enabled Transit Information Applications Contactless payment and transit ticketing are not the only applications supported by NFC technology. Other applications, such as service discovery, loyalty and frequent-user cards, coupons, event tickets, and logical and physical access control, can be stored on NFC-enabled mobile phones. These applications can then be used to collect points, enjoy rebates and events, or access information services. For example, a 2007 Transport for London pilot tested NFC-enabled phones and “smart” posters. Passengers in the trial entered a destination into their phone and, upon transferring to another line, touched the phone to a poster. The phone’s handset screen instantly provided detailed travel information, including a map of the station and surrounding area and real-time travel information.

10.1.5.2.3 Summary Through the various field trials, full system implementations in Asia, and a variety of market and focus group studies, it has been continually demonstrated that transit patrons warmly embrace mobile fare payment and associated real-time information services. User acceptance rates are very high with the participants citing convenience, access to information (e.g., account balance and status), and transit service data all offering substantial value. These user benefits can be offered to consumers in both closed loop transit card systems or in open loop environments, such as those now being introduced to markets such as London, Chicago, Philadelphia and Washington, DC.

10.2 Parking130 This public parking market is characterized by three primary segments, defined by different operational practices:  Entry-/exit-controlled garages and surface lots  Open surface lots and garages  On-street parking Systems and payment practices vary significantly across these segments, and historically each segment has tended to use different solution providers. In terms of technology and systems, parking revenue automation has developed in parallel with mass transit automation. Currently deployed solutions incorporate the use of a wide range of technologies (e.g., read/write magnetic tickets, bar code tickets, RFID and proximity devices, automatic vehicle identification (AVI) systems, smart cards), currency validation components, and both attended and unattended credit card processing. One characteristic that distinguishes the parking market from the transit market, however, is the amount of fragmentation in the industry. This fragmentation has led to the presence of significant

130 Source: Smart Cards and Parking, Smart Card Alliance white paper, January 2006

amounts of aging payment infrastructure, management companies with poorly aggregated data and audit controls, and facilities that are particularly prone to credit card fraud and other forms of loss. In the on-street market, the industry is looking for the most effective parking solution possible. Many in that market are motivated to introduce changes to their existing infrastructure by a strong desire to enable or increase cashless payments (including credit card) as well as to improve data collection and respond to patron desires to receive receipts. Considering the online communication requirement necessary for credit card transactions and the fact that currently there is no viable single-space solution to enable them, some municipalities are turning to more sophisticated multi-space pay stations incorporated into regional wireless networks. While these features are often achieved with the new pay stations, new challenges arise including costs and enforcement (e.g., for motorcycles and convertibles). Regardless of whether single-space meters or multi-space pay stations are the best for on-street applications, the desire to increase the use of cashless payment and improve data collection in on-street parking equipment are at least two of the factors motivating changes in the parking industry. When these factors are coupled with the new credit card processing requirements imposed by the payment brands (lack of conformance to which creates significant financial risk), the climate created is similar to that of the late-1990s transit industry. A wave of investment in payment technology and infrastructure has already begun and will continue for the next several years. The opportunity currently exists for transit and parking entities to leverage common standards, systems, technology, and support infrastructure to make overall operations more cost-effective and add value for the consumer.

10.2.1 Parking Market Segments Parking is provided by a broad spectrum of public and private entities and, in most cases, fees are collected to pay for this valuable service. The mechanisms for fee collection vary, not only by service provider but also by whether parking is on-street.

10.2.1.1 On-Street Parking On-street parking is primarily the domain of municipal parking programs, although some campus, hospital, transit, and airport parking programs include paid curbside parking. On-street meter programs are typically implemented and managed by municipal parking agencies. The outsourcing of municipal meter operations is a recent development, and companies are selected via competitive procurements to provide these services. The services include meter installation, maintenance, and fee collection. Because on-street spaces are typically the most convenient, both in terms of accessibility to the motorist and accessibility to nearby places of business, these spaces must be carefully regulated to ensure that they are not monopolized by long-term parkers. On-street spaces must turn over frequently, and frequent turnover is typically encouraged by imposing time limits on their use. However, time limits alone are not adequate. There must also be a mechanism for enforcing these time limits, and the ubiquitous single-space parking meter is a well-established tool for enforcing these regulations. Paid or unpaid status determines whether a parker is in compliance with the time limit. While the initial intent of using parking meters was regulatory, parking meters generate another obvious benefit—revenue. Municipalities now use parking meters both to control the use of curb space and to generate much-needed revenue.

10.2.1.2 Single-Space Meters Today’s single-space parking meter does not look significantly different from the meters that were deployed decades ago. However, the materials used to manufacture the meter shell and the

timing mechanism have changed considerably. The shells have gone from steel to cast iron or zinc alloy, to improve durability and reduce vandalism. The mechanisms have evolved from springs and gears to electronic components, a development that opened the door for the use of contact smart cards. Single-space meters are low cost and easy to maintain. They are almost always conveniently located near the user’s parked car and they are easy for the parking public to understand and use. Typically, single-space meters accept coins, tokens, and often contact smart cards. Single-space electronic meters are powered by low voltage batteries and are currently incapable of the online communications necessary for remote monitoring and online payment card processing. They also are required to fit into meter housings that have, for the most part, been standardized across the industry. These power and space constraints limit the ability of most such meters to house the RF transceiver required for contactless smart cards. Data is typically collected using handheld data terminals that periodically probe the devices. In addition to the traditional single space meters found worldwide, meters with magnetic vehicle sense coils buried in the parking space are making headway in a number of municipalities in France, The town of Issy-les-Moulineaux and approximately 60 other towns have installed this new technology. The meter senses the time of arrival and the time remaining after payment. If the vehicle leaves the spot before the time expires, the meter resets to zero time for the next vehicle. However, if the time runs out and the vehicle is still parked, a digital message is sent from the meter to alert the parking authority of an overtime parker. Revenue increases have been observed.

10.2.1.3 Multi-space Meters While single-space meters have long been a fixture on the parking landscape, new technology is now starting to be deployed. The operational constraints imposed by single-space meters (described above) have led most of the market outside North America to embrace multi-space meters, which are more sophisticated curbside payment devices. Multi-space meters accept payment for parking at multiple available spaces (either on- or off-street). Multi-space meters support a variety of online functions and a wider array of payment options. Due to their cost, they are typically configured to manage multiple spaces in a single block and provide wireless online communications necessary for real-time credit card processing and remote monitoring. Industry norms are in the range of 8 to 10 on-street spaces per meter. Networked systems also provide value-added features such as paying by cell phone. Figure 33 shows examples of typical multi- space meters. Figure 33. Multi-Space Meter Examples131

131 Sources: MacKay Meters, Parkeon, Reino, Cubic Parking Systems

Most on-street multi-space meters operate in pay-and-display mode, in which a receipt is printed by a machine that documents the time purchased. This receipt is then placed on the dashboard for visual inspection by enforcement personnel. An alternative to pay-and-display is pay-by- space. In this scenario, spaces are numbered, and the machine logs the time purchased by space number. A printed or electronically retrieved manifest is then used for enforcement. Wireless handheld computers compliment enforcement capabilities, providing access to the paid- space database and facilitating violation issuance. Multi-space meters are powered by either AC power or larger batteries (often trickle-charged using a solar cell), incorporate the use of wireless communications technology, and facilitate the use of credit and debit cards as well as coins and tokens for payment. Their expanded power capacity makes possible the incorporation of the RF transceivers required by contactless smart card technologies. The machines sit on real-time networks that can communicate alerts and need for collection and/or service, as well as enabling more sophisticated asset management and revenue reporting. An additional recent development links municipal on-street programs using regional wireless networks. Multi-space meters are also proving to be a cost-effective alternative for collecting parking fees in off-street surface parking lots. In addition to the obvious benefit of needing fewer devices, there are indirect cost savings. Single-space meters cannot accept credit/debit cards and have limited coin storage capacity, so manual coin collection is required. Both collection and maintenance costs can be reduced if multi-space meter operations are managed effectively.

10.2.1.4 Off-street Parking The parking demands of commuters or motorists who have business that requires more than a 1- to 2-hour visit are served by off-street parking, including surface lots and under- and above- ground parking structures. The location of these facilities is typically dictated by population density. These garages are stand-alone facilities or part of another structure and are operated by a larger group of real estate and facilities owners as well as by municipalities, port districts, stadium authorities, universities, and hospitals. Because off-street parking facilities are expensive to construct, there must be a sound value proposition for building them. The value proposition is typically based on the level of demand created by parking generators, including office, residential and hotel/casino use for private sector garages and general, mass event, and office use for public sector garages. Regardless of the business case for construction, once such parking facilities are in operation, management is often outsourced to private parking operators. Off-street parking facilities are expensive to construct, but they also generate a significant amount of revenue. The cities with the greatest urban density typically have the highest rates. Regardless of either the amount of revenue collected at a facility or the entity responsible for collecting it, revenue “shrinkage” due to employee pilferage and customer fraud is an issue. To address this issue, the industry is deploying increasingly sophisticated revenue/access control systems. These systems use a variety of electronic media (e.g., bar code, proximity reader, debit system, magnetic stripe, automatic vehicle identification technology), and some systems use more than one type of medium. The primary objectives of these revenue control systems are (1) to reduce or minimize employee contact with cash, (2) to close loopholes that enable customers to pay less than the required fee or avoid payment altogether, and (3) to improve auditability. A significant additional benefit of such systems is that the data they collect can be used to generate reports on the financial and operational performance of a particular garage or, in some cases, multiple facilities.

Revenue control for collecting off-street parking fees is primarily accomplished using one of two operational models. The first model is used where the length of stay is the basis for pricing. It uses equipment that controls access at both entry and exit points. These systems calculate hourly fees by recording entry and exit times. In the past, systems of this type typically employed a cashier to collect system-calculated fees at the point of exit. However, such systems are now incorporating credit-card-in—credit-card-out capabilities to eliminate cashier involvement and expedite egress. One variation of this type of system incorporates pay-on-foot or central pay stations. Tickets generated at the point of entry are inserted into a pay station located in the garage or at the nearby generator, and cash or credit card payment is made at this point. The ticket is updated to reflect payment and reissued for insertion into the exit lane controller. Central pay stations have been used extensively in Europe and are now gaining popularity in North America. The second operational model utilizes the pay-and-display or pay-by-space metering approach. The choice of operational model is largely influenced by lot size and how susceptible the facility is to peak traffic flows. Unstaffed entry–exit systems accelerate payment processing and move people out of a facility quickly, enhancing user convenience. In both cases, online connectivity is key to the effective processing of credit and debit transactions and to the remote monitoring and reporting functions. Entry–exit systems, in particular, depend on communications. The ability to serve the patron remotely is crucial to preventing a vehicle from being trapped. Systems often incorporate the use of live intercoms to communicate with centralized service personnel. The electronic media used include bar code tickets, magnetic tickets, RFID cards, and credit cards. Encoded tickets carry entry information, enabling local rate table lookup at exit. RFID and credit cards are sometimes processed at entry, updating a back-end database that is then searched at exit to calculate the fee. The use of smart cards can take the place of the encoded ticket. In order to distribute patron flow and avoid queuing at the exit lane, pay-on-foot stations are often the point at which the rate is calculated and payment accepted. The media issued at entry is coded for exit when payment is accepted, and the exit equipment permits egress upon proper validation. Cashier terminals often compliment pay-on-foot stations to avoid the delays that can result when patrons fail to visit the machine.

10.2.2 Use of Smart Card Technology in Parking Use of contact smart card technology is well established in the parking market, with vendors providing solutions for all segments: single-space meters, multi-space meters, and off-street parking. The large parking vendors have installed closed-loop contact smart card solutions in many cities, including: New York, NY; Portland, Oregon; Hong Kong, China; Paris, France; Ottawa, Canada; San Francisco, California. The parking operator issues (and reissues) the smart cards, manages retail outlets (where they exist), manages cardholder queries, reloads the cards (where this is possible), and manages the entire card system. Many of the cities implementing smart cards are doing so by leveraging their existing meter infrastructure, replacing single-space meters with smart card-enabled single-space meters. Others are upgrading their single-space meters to accept smart cards and adding additional multi-space meters where appropriate. In those cities, the multi-space meters and single-space meters share the same smart card program, and multi-space meters anywhere in the city can be used to load value onto the smart cards. Some of these solutions only work with one parking payment vendor’s technology, although there are instances of collaboration between non-competing vendors in some cities. The current implementations are restricted to one type of parking operator (either public or private), with no cross-operator implementations (for example, between public and private operators). Other

solutions being implemented allow multiple cities to take part in a single collaborative parking payment system using smart cards. In these systems, a third party manages and operates the smart card payment system on behalf of the participating cities. Meters accepting smart cards typically also accept coins, and, in the case of multi-space meters, bills and magnetic stripe credit/debit cards. The smart card solutions for on-street parking have primarily been based on both the ISO/IEC 7816 standard and proprietary smart card technologies, depending on the age of the solution.132 With the growth in the use of multi-space technology, the door has been opened for the use of ISO/IEC 14443 contactless smart cards as well. In addition to specific smart card-based parking programs implemented by municipalities, transit authorities around the world have implemented a model that allows the same contactless smart card fare medium that is used to pay for transit fares to also pay for parking. Examples of this model include Washington DC (Washington Metropolitan Area Transit Authority (WMATA) SmartTrip card), Metropolitan Atlanta Rapid Transit Authority Breeze card, Hong Kong Octopus card and Singapore EZ-Link card. The security used in the different smart card solutions is implementation-specific and ranges from the use of passwords to unlock the cards to DES-based cryptography. Most meters that contain security information store it in the memory of the meter, although some contain security access modules (SAMs). The SAM stores cryptographic algorithms and the keys used to encrypt and decrypt messages securely. The smart cards can typically be used only to buy time at the meters, although there are solutions with enough security to allow the cards to be used to purchase items from local merchants. Historically, the adoption rates for contact smart card systems have been low. Many cities record usage rates in single-figure percentages. Low usage rates have been attributed to the lack of an effective card distribution and reload infrastructure, the lack of an effective card marketing plan (for which cities typically lack budget and expertise), and the fact that the cards can only be used to pay for agency-specific parking and, typically, must be purchased from a city-authorized agent. Most implementations have used simple memory cards that cannot be reloaded, forcing the patron to purchase another card when the stored value in the first card has been used up. Some newer systems allow cards to be reloaded at a variety of terminals and over the Internet. Cardholders can also subscribe to auto-load programs, in which a link to a credit or debit card account enables the stored value to be replenished automatically, without forcing the patron to purchase a new card or find a reload location. If implemented properly, however, a smart card system can allow a city to increase revenues dramatically. The city can increase rates on existing meters without incurring the high initial replacement costs associated with implementing a completely new system.

10.2.3 Smart Card Benefits for Parking Smart card technology is the clear leader for on-street and short-term electronic parking payments. By implementing smart card technologies, parking operators can take advantage of the increasing consumer preference for electronic payments and achieve significant benefits.

132 There are some exceptions. In 1997, the Hong Kong Transportation Department initially upgraded all of its on-street mechanical coin-operated parking meters with 19,500 battery-powered electronic parking meters that only accepted payment from a disposable contact stored value smart card solely used for parking. Then in 2004, following a number of pilots and trials, the on-street single- and multi-space meter equipment was again upgraded so that it only accepted payment by the City’s very popular Octopus card, which is based on technology that is similar to the ISO/IEC 14443 standard.

10.2.3.1 Better Customer Service Smart card technology has the potential to allow customers to use one card both for parking and for other payments, such as transit, tolls, or small purchases. While customers appreciate the convenience of being able to use a single card for a variety of uses, parking operators can also spread the cost of operating the smart card system over a larger number of transactions and share the costs with other application providers. For example, schemes such as the Hong Kong Octopus card and Washington SmarTrip card (see Sections 11.1.3 and 11.1.1 , respectively) allow customers to use one payment card to pay for parking at multiple sites over a large geographic area. Smart cards, due to their strong security features, do not necessarily require the same level of user verification (i.e., a signature) as credit cards. This advantage can result in reduced transaction times, lowering customer wait times. Smart card applications can protect users if their cards are lost or stolen. For example, a smart card can be disabled by the terminal at first use after the card is reported lost or stolen. This capability allows parking operators to ensure that customers suffer no financial loss while minimizing the cost of providing such service. Customers using contactless smart cards never need to let the card leave their hands. Presenting the smart card to the reader enables the terminal to scan the card for user data and encode relevant data into the chip for future use. If the card is a contactless payment card, the terminal processes the transaction without the danger that the card may be captured and not returned due to equipment malfunction. This capability can be particularly beneficial at gated parking locations, such as airports. For parking applications that calculate fees according to length of stay, entry data can be encoded into the card’s chip memory and then accessed for rate table lookup. This capability eliminates the need to issue magnetic or barcode tickets, increasing customer satisfaction. Stored value or contactless credit card systems allow customers to avoid even visiting a pay-on- foot machine; the exit terminal calculates the fee and debits the transaction from the card in less than 1 second. Smart cards allow parking operators to charge motorists only for the amount of parking time actually used. Motorists find this to be a much fairer system and the parking operator benefits by achieving a higher turnover at each parking space, since these types of systems reduce the ability for motorists to “feed the meter.” For example, in Saskatoon, Saskatchewan, Canada, motorists use a smart card to purchase the maximum time allowed at a particular meter. When they return, they reinsert the card, which is then credited for any unused time, and the meter is set back to zero. Another customer service example is the University of Wisconsin Flex Parking Program, which has implemented personal parking meters that hang on a car’s rear-view mirror and work in conjunction with prepaid smart cards. The personal parking meter tracks the time and subtracts the required amount directly from the smart card. Unlike traditional parking permits, personal parking meters can pay for only the precise amount of parking time used. The meters also allow faculty the option of parking in staff and public spaces. The personal parking meters therefore allow users to park in more locations than the traditional permit, and offer the flexibility of infrequent parking for those users who opt to use alternative modes of transportation. Smart cards make it easy for motorists to maintain value on their cards, thus encouraging use of parking services that accept smart card-enabled payments. For example, SmarTrip and Octopus cards that allow payment for parking can automatically be topped-up when the amount in the card falls below a predefined level. Smart cards can also be recharged manually at kiosks, retail locations, and gas stations, using traditional payment methods like cash and credit/debit cards.

10.2.3.2 Increased Revenues Smart cards increase motorists’ willingness to pay at the meter. In most cases, motorists have only one choice for payment which, for a single-space meter, is generally coins. If motorists do not have the correct coins, they are more likely to simply risk a ticket. Studies have shown that offering flexibility in payment options can increase motorist compliance by as much as 20%, thereby increasing revenues for the parking operator. Another source of increased revenue is increased rates for on-street parking. Local governments have been reluctant to raise rates to market levels, fearing that motorists would resent not only the higher rates but also the need to carry more coins. However, the City of San Francisco recently approved significant on-street parking rate increases (from $2 to $3 per hour in the city center). These increases were approved because the city is implementing a MacKay Meters smart card payment system for parking meters, thus offering motorists an alternative method of payment. Since smart cards can eliminate the need for coins, consumers are also likely to increase their use of on-street parking, rather than searching for off-street parking in less convenient areas. Businesses located in city centers often claim that they have a disadvantage when competing against businesses located in suburban areas, where parking is free. While there is no direct evidence to suggest that card payment options for on-street parking provide downtown businesses with any competitive advantage over suburban shopping locations, the City of Portland has found that more people choose on-street locations when they can pay by card. In addition, it appears that in Portland the average card transaction is approximately $2, while the average coin transaction is approximately $0.70. The implication is that people park for longer periods and shop for longer periods when they use cards to purchase parking. Smart card-based electronic purses may also provide parking operators with a benefit by allowing them to accrue interest on funds that the customer has prepaid. The more cash there is in the bank (as opposed to the machine), the more interest the operator earns on the money. In addition, transaction amounts tend to be higher when customers pay with credit, debit, or stored value card payments as opposed to cash.

10.2.3.3 Increased Operational Efficiency Using smart cards can increase the efficiency of parking operations in several areas: security; labor requirements, and equipment. Smart card systems incorporate advanced security features that reduce the risks associated with not having every transaction authenticated by a back-end management system. Parking operators need not incur the cost of installing and maintaining a full-time communication link for each parking device. Electronic parking payments also provide economies of scale that are not available for labor- intensive processes like servicing coin-operated parking meters. The incremental cost for each additional smart card transaction declines sharply, in comparison to the transaction costs incurred using coin-operated parking meters. In addition, reduced transaction times mean that fewer staff (or gates) are required at off-street parking facilities. If the smart card used for parking is also used for other applications, parking operators can spread the cost of operating the smart card system over a larger number of transactions and share the costs with other application providers. Other benefits can be realized in lower equipment and material costs. Cash-handling systems are complicated electromechanical assemblies that suffer from extensive wear and tear and intermittent failure. They are expensive to design, build, and maintain. Using smart cards can decrease failure potential and repair costs and also decrease the cost of consumables, such as the ticket stock associated with entry/exit systems.

However, parking operators must take into consideration that as long as cash continues to be accepted for payment, the unit cost of handling cash will increase as the percentage of total revenues collected from cards increases.

10.2.3.4 Stronger Internal Controls and Security Cash-heavy businesses in general are vulnerable to errors made while handling cash. By reducing cash-handling requirements, smart card parking meters strengthen internal controls, reducing opportunities for inaccuracies. Smart card technology incorporates stronger security features than any token or payment card technology. Applications can leverage the many security features supported by smart cards to ensure the integrity, confidentiality, and privacy of stored or transmitted information and to counter potential security threats. Smart card systems are much harder to compromise than magnetic stripe systems, decreasing the losses experienced by parking operators due to fraud. This is one reason that credit card issuers in Europe and elsewhere are now issuing smart card- based credit cards. Smart cards also have extensive built-in tamper resistance. A variety of hardware and software capabilities can detect and react to tampering attempts immediately. The ability to support authenticated and authorized information access combined with strong data security make smart chip-based devices excellent guardians of personal information and individual privacy. Consequently, implementing a smart card system allows parking operators to assure motorists that effective security measures are used to protect their personal information. Cash left in parking meters between collection cycles can be an enticing opportunity for vandals and thieves. Smart card-enabled parking meters reduce the amount of cash present in meters, thus reducing the potential and incentive for vandalism. However, it should be noted that without adequate security and controls, the reduction in physical vandalism can be offset by an increased potential for other types of fraudulent activities, such as the use of counterfeit cards, issues with reconciliation of tendered revenues with the cash receipts from the sale of cards, and theft of cards.

10.2.3.5 Expanded Strategic Marketing Opportunities Smart cards can capture critical operational data. Captured operational data can then be analyzed to enable strategic marketing schemes such as increased price points, loyalty reward programs, payroll deductions, corporate billing, customer relationship management, and usage forecasting applications. The promise of mining such data has long been discussed; however, the majority of smart card programs have yet to reach sufficient maturity and the necessary standards have been lacking for this promise to be fulfilled. That said, a new era in the market place is coming where payment card issuers and transit collectives are embracing common technology, while interoperability standards are nearing completion. In addition, large-scale infrastructure deployments are being completed with major card roll-outs approaching. The new systems are offering a variety of “opt-in” web-based facilities that will create the mechanisms for commercial agreements surrounding shared data and applications. Discussions are taking place between transit agencies, financial institutions, online ticketing firms, parking operators, and venue managers, just to name a few. For those municipalities deploying multi-space on-street metering programs, smart cards make a significant new revenue opportunity available. The municipality can offer load services using the meter infrastructure. For example, transit agencies are constantly looking for ways to provide convenient reload capability for bus riders. Current strategies include placing specially equipped terminals in selected retail locations. By providing a contactless transceiver on a parking meter, the meter could accept currency and credit and debit cards in payment and facilitate the sale of stored value or pass products on behalf of the transit agency. By doing so, a municipality may be eligible for the commission typically paid to a retail merchant. As smart card programs

increasingly support multiple applications, the opportunity to use the meters to sell a diverse range of digital products is possible. Smart cards allow parking lot vendors to offer consumer loyalty benefits and subsidized parking programs in partnership with local merchants. In addition, discounts can be offered to selected consumer classes like students, senior citizens, or clergy. Zoning and preferential parking rates can be offered to residents. In places like Hong Kong and Korea, co-branded cards are being issued, smart objects (e.g., watches) are being sold and non-transit applications are being supported on cards issued primarily for transit payment. Examples include retail payment, recreational facilities access, parking payment, and security access control. The forecasted promise appears to be arriving.

10.2.3.6 Simplified Tax Benefits Administration Beginning March 1, 2009, U.S. employers can provide employees with a tax-free or pre-tax transit benefit allowance of up to $230 per month133 and a parking benefit of up to $230 per month134. A smart card payment system can reduce or eliminate the need for employers to purchase and distribute paper transit/parking benefit checks to employees. In addition, a parking operator can easily accept and process smart card transactions. The paperless smart card-enabled payment system allows employers to simply update a cardholder database and perform an electronic funds transfer. The system can then electronically distribute the benefit to the smart card at the next point of use (train station, bus, or parking lot). Similarly, employers can provide their employees with prepaid smart cards to use for local business travel. Both employees and employers can then receive a single monthly statement for all parking payments, eliminating the need to store or acquire individual receipts. This valuable service may encourage motorists to use the operator’s facilities over others.

10.2.3.7 Compliance with Laws/Statutes Many municipalities collect taxes on the parking revenues generated by private operators. But the cash-only systems common in private lots do not generate an effective audit trail, putting the operator at risk of being accused of tax evasion. State-of-the-art revenue control parking equipment ensures that reporting is accurate and correct rates are charged. By implementing a smart card system, a parking operator can eliminate the need to purchase and maintain parking machines, using only a handheld computer to collect parking fees from motorists securely.

133 http://www.wmata.com/about_metro/news/PressReleaseDetail.cfm?ReleaseID=2474 134 http://www.wmata.com/about_metro/news/PressReleaseDetail.cfm?ReleaseID=2474

11 Sample Smart Card Payment Models

11.1 Transit135 This section profiles three different transit programs, each of which implements a smart card- based payment model, including:  Washington Metropolitan Area Transit Authority and surrounding area, who implemented a region-wide closed system contactless fare payment card  Utah Transit Authority, who accepts both a closed system contactless fare payment card and open credit and debit payment cards  Hong Kong Octopus Card, who implemented a closed system contactless fare payment card for transit which can now be used at general retail locations

11.1.1 Washington Metropolitan Area Transit Authority and Surrounding Area The major public transit operator in the Washington, DC, marketplace is WMATA, which is an interstate compact agency. WMATA operates the local subway system (Metrorail, with 86 stations, 106 miles) and a regional bus system (Metrobus, with 1,450 buses) with ridership of approximately 1.3 million trips per day. WMATA was the first transit authority to push aggressively for the use of smart cards in its systems. WMATA has been using the SmarTrip® card (based on the Cubic Gocard) for Metrorail and parking since May 1999. The Metrobus system became fully SmarTrip capable in August 2004, and a series of contracts are in place between the system provider and multiple independent transit agencies throughout the State of Maryland, the District of Columbia, and Northern Virginia to expand SmarTrip acceptance throughout the region. Now 12 agencies accept SmarTrip, with over 8,000 processing devices deployed. Since its launch, WMATA has issued over 2.5 million SmarTrip cards. The SmarTrip card is available as a stored value card (up to $300) for full-fare and reduced-fare customers. A SmartBenefit service allows the cards to be electronically loaded with transit benefits. In June 2004, SmarTrip became the only form of payment accepted at Metro-operated parking lots. (See Section 11.2.1 for additional information on WMATA's parking implementation.) To handle card availability and distribution, WMATA placed card dispensers in each of its rail stations with parking facilities. This mandatory use of the card at parking facilities resulted in a surge in the quantity of cards sold. During the first year of automated card vending, WMATA sold over 700,000 SmarTrip cards, of which 80% were sold from the card dispensers. In 2005, WMATA and Citibank teamed up to offer the Citi® Platinum Select® SmarTrip MasterCard, a combination Metro SmarTrip card and Citibank credit card. As an added benefit to the SmarTrip program, customers receive 5% back as a statement credit for 6 months (up to $300) when they use the card to pay for Metrorail and Metrobus fares or Metro-operated parking. The pilot ran from November 2005 to July 2009 and was very popular with the customers. Success of this pilot was a key indicator to advance the open payments program at WMATA.

135 Sources: Smart Card Alliance white papers

In 2010, the Maryland Mass Transit Authority began issuance of the Charm card developed using common specifications with SmarTrip. Each agency will cross honor the two interoperable smart card products. The WMATA smart card distribution network includes retail stores and mail-order options. At WMATA parking locations, the organization relies on vending machines that sell cards with value to patrons requiring the mandatory card to park. The addition of these vending machines has sharply increased the penetration rate of the cards. In 2014, WMATA awarded the contract to replace the existing fare collection systems for Metrorail, Metro-operated parking facilities, Metrobus and MetroAccess services. According to WMATA, “the new system will be designed to provide a state of the art system for Metro customers that enables them to continue to use SmarTrip cards, while expanding fare payment to chip-enabled credit cards, federal government ID cards, and mobile phones using near field communications (NFC). When fully deployed, customers will see approximately 1,000 faregates including ADA faregates, 450 fare vending machines, approximately 1,500 bus payment targets, approximately 160 new payment targets at parking exit lanes, and approximately 600 NEPP- compatible smartphones for MetroAccess operators. The new system will not accept paper tickets and Metro will continue the gradual phasing out of paper fare media.136 WMATA has been piloting the system since October 2014.

11.1.2 Utah Transit Authority137 The Utah Transit Authority (UTA) is the regional transit provider for the primary urbanized areas of Utah. Its service area primarily consists of a 100 by 20 mile corridor bounded by the west face of the Wasatch Mountains and the Great Salt Lake and Utah Lake. A population of 1.8 million is served. UTA operates 520 buses out of four garages, 80 paratransit vehicles, four light rail lines over 35 miles, and a 44-mile commuter rail line. Two additional light rail lines and a doubling of commuter rail mileage will be added by 2015. When UTA began its investigation of electronic fare collection systems in 2005, its primary concerns were, and continue to be: the convenience and ease of use for its customers; the efficiency and effectiveness of revenue collection; and the data that could be gleaned to understand transit system use and guide service planning. UTA started its effort with virtually no legacy in automated fare collection systems, and was therefore free to explore the latest advances and opportunities in fare collection technology. At that time, the payments industry had just announced its launch of contactless media under the brands of American Express ExpressPay, MasterCard PayPass and Visa payWave. Acceptance of contactless credit and debit cards issued by banks and other financial institutions for direct payment of transit fares was appealing to UTA for the following factors:  Issuance of payment media by other organizations  Integration with the payments mainstream: payment at the fare box, gate or platform as a merchant POS transaction  Automatic interagency interoperability  Customer service with issuers  Security standards  Flexible architecture for product development  Robustness of the open payments ecosystem

136 “Washington Metro awards Accenture major contract for new electronic fare payment system to improve customer experience,” WMATA press release, January 8, 2014, http://www.wmata.com/about_metro/news/PressReleaseDetail.cfm?ReleaseID=5637 137 Sources: http://www.rideuta.com/electronicfare; UTA Electronic Fare Collection System: Development Progress Report, Craig Roberts, UTA, presentation, 2009 Payments Councils Summit, February 25, 2009

 Commoditization of devices  Potential for a pathway to eliminate cash  Speed of deployment  Cost  Co-promotion by issuers In 2006, UTA began an electronic fare collection pilot on 41 ski service buses. The purpose of the pilot was to learn about the development and deployment of such a system by actually operating it on a manageable number of buses. The pilot objectives were to: (1) solve an immediate problem – accounting for the use of resort customer season and employee passes issued by and paid for by ski resorts; and (2) learn whether transit fares could be collected using the new contactless open credit and debit cards being issued under the open payment brands. As partners in the pilot, each of four ski resorts issued picture passes with contactless technology embedded. Based on its concurrent experience on open payments in the first New York City Transit pilot, MasterCard agreed to participate in the Utah pilot. American Express and Visa also agreed to participate. The pilot was deemed a success. UTA was able to learn about most of the processes that it would need to manage in a full system deployment. All of the internal and external stakeholders interested in the system were able to get real-world exposure to the technology. The pilot was continued for another year. UTA decided to aggressively proceed to build and deploy an open payments fare collection system on all of its fixed route bus and rail service. Included would be support for its third party paid pass program associated with employers, universities and ski resorts. On January 1, 2009, UTA launched the new system. It included: an infrastructure of readers at all doors of 520 fixed route buses and 170 validators installed on 35 TRAX light rail and FrontRunner commuter rail platforms; wireless communications gateways on buses with both 3G connectivity and WiFi connections at garages and optical fiber to all platforms; and Internet links from each device to a hosted back office. The initial fare products were contactless bank card acceptance for single adult fares, including honor of transfer rules and use of third party paid passes (ECO Pass for employers, Ed Pass for colleges and universities, and Ski Pass for five ski resorts within the UTA service area). Special characteristics of the UTA system architecture include:  Tap-on/tap-off. Tapping at the entrance and exit of each bus or rail trip segment allows collection of linked origin/destination data that is invaluable for service planning. It also provides information necessary for calculating distance-based fares for commuter services and possible migration to such fare pricing system-wide.  Account based architecture. Fares are calculated and transactions are processed in the back office easing implementation of fare changes and creation and launch of new fare products.  Open payments acceptance. The system and card acceptance devices are certified and process contactless cards issued under the American Express ExpressPay, Discover Zip, MasterCard PayPass and Visa payWave brands.  Hosted back office. The back office is connected through the Internet to each device, enabling flexibility and portability and easing PCI compliance.  Cold and hot lists. A list of third-party pass card numbers to be accepted are maintained on each validator and in the back office as submitted or modified by the ECO, Ed and Ski pass card issuers. Bank cards that are declined by issuers are placed on hot lists that speed their rejection.

 Near-real-time and real-time authentication. In the initial launch with bank cards, the price of each trip is calculated as the tap-on/tap-off actions are received and then submitted for full authorization and settlement. If the card is declined, it is hot listed and will not be accepted by the system going forward unless and until the customer arranges for payment for the unpaid trip and card acceptance is restored. Real-time authentication will be added as the technical viability and business case for that approach is demonstrated.  Inspection. Inspection devices for proof-of-payment rail services are using NFC and 3G smart phones to interrogate payment cards and determine through the back office that they had been previously presented and accepted by the platform validators. UTA is unusual as a merchant accepting open payment brand products directly for access to its transit vehicles in that it accepts contactless media only. It requires transaction speeds of 300 milliseconds from presentation of a card to the green or red light response. The price of the trip is determined in the back office only after completion of the trip with tap-on/tap-off. Ultimately, it must assure that media for use in its system are available to all of its customers, including those who do not have banking relationships with credit and debit cards. Privacy has been a priority and has been addressed from the initial planning of the electronic fare collection system. UTA values the linked origination-destination data enabled by this system for service evaluation and planning, but does not need nor want to know who is traveling. Third- party payers keep the identities of those individuals who are authorized to ride and provide UTA only with the card numbers. UTA provides information about system use by third party employees or students in an aggregated form. For open payment bank card acceptance, the hosted back office contractor separately maintains records and processes for the application of business rules and credit/debit processing. Customer security is also assured by contractor and agency compliance with PCI DSS. Additional fare products and functions are now in the process of development, including:  Special fares for seniors and disabled individuals  Gift card or closed loop prepaid programs  Open loop prepaid partnerships  Contactless co-branded cards  Acceptance of government benefits distribution cards  Federal Personal Identity Verification (PIV) card use for administering employee transportation benefits  Use of third-party access and identity media for prepaid or post-paid payment per trip  System-wide pay-per-trip distance-based fares

11.1.3 Hong Kong Octopus Card138 The Hong Kong Octopus card was launched in 1997 as an electronic purse for public transportation. The card’s acceptance and popularity have since extended its use to nearby retailers. Octopus cards were developed as an automatic fare collection (AFC) scheme for Hong Kong’s transit system. The Octopus system currently includes all of the major transport operators (bus, taxi, subway, train, tram, and ferry services). Because Hong Kong's main transport operators are all partners in the Octopus card, kiosks are widely available, making it easy for customers to check the balance on a card and recharge it with cash or electronic payments. The use of the card has shortened queues at ticket barriers, because the card doesn't have to be taken out of a bag or wallet — customers can just wave it past a scanner at a distance of several centimeters.

138 Hong Kong Octopus Card, Smart Card Alliance profile, 2005, with updates from Cubic and Octopus web site

The first non-transit applications for the Octopus card allowed the card to be used for payment at photo booths located in the Mass Transit Railway (MTR) stations and pay phones operated by New World Telephone. The Octopus system currently includes public transportation services, apparel stores, bakeries, car parks, cinemas, convenience stores, fast food chains, household stores, leisure facilities, personal care stores, photo finishing stores, photocopiers, supermarkets, and vending machines. Octopus cards are also used on school campuses and at residential and office facilities also use Octopus for building access control.139 Octopus cardholders are also able to use account-linked payment, where the value is maintained in a back-end system and charges are billed to the individual's credit card.140 An Octopus Rewards program is also offered. Retail payment does not have to be via Octopus as rewards can be earned with cash, credit, or Octopus payment methods. The contactless Octopus card is based on Sony’s FeliCa™ technology, a proprietary 13.56 MHz technology similar to but not compliant with the ISO/IEC 14443 standard. This technology has widespread acceptance in the Asia Pacific region, with over 25 million cards issued worldwide, according to JCB International Credit Card Company. Terminals read the cards instantly, processing transactions in less than one-third of a second. On the MTR, a scanner at the ticket barrier loads data on the card that is then used by scanners at the exit gates to deduct the correct fare and show the remaining credit. In 2002, the Asia Pacific Smart Card Association reported that 95% of the “economically active population” was using the Octopus card. Travelers have found that the card provides increased convenience, allowing them to pass through fare collection points 15 to 20% faster, according to Octopus card statistics. The scheme has succeeded because it offers real convenience to cardholders.

11.2 Parking141 This section profiles two different parking programs, one in Washington, DC and one in Israel, each of which implements a different smart card-based payment model.

11.2.1 Washington Metropolitan Area Transit Authority As described in Section 11.1.1, WMATA has been using a contactless transit fare payment card, SmarTrip, since 1999. WMATA is also the largest parking operator in the region, with over 55,000 parking spaces at 35 subway stations, including both surface lots and parking garages. Throughout most of WMATA’s operating history, parking operations have been handled through third parties. WMATA has been using SmarTrip for the subway and for parking since May 1999. The subway and bus contactless smart card fare collection systems are tightly controlled and provide both revenue and a wealth of information about passengers. In contrast, the WMATA parking facilities were viewed as losing large amounts annually; cash was the primary way customers paid for parking. As a result, in early 2004 the WMATA Board of Directors decided to shift the direction of parking operations and institute cashless parking at all WMATA lots, effective June 27, 2004. This gave WMATA staff about 120 days to replace the parking lot attendants and the existing payment infrastructure.

139 http://www.octopuscards.com/consumer/payment/use/en/index.jsp 140 Ibid. 141 Source: Smart Cards and Parking, Smart Card Alliance white paper, January 2006

11.2.1.1 SmarTrip Dispenser Introduced To handle the problem of card availability and distribution, WMATA contracted with Lexis Systems (now Cubic Parking Systems, a new business unit for Cubic Transportation Systems) to purchase 55 card dispensers to be placed in each Metrorail station that had parking facilities. Several stations with large parking facilities received multiple devices to assure sufficient sales capacity. The dispensers are equipped with bill validators and accept $1, $5, $10, and $20 bills. They do not escrow bills, give change, or issue receipts. The devices accept Visa, MasterCard, Discover, and American Express credit cards with zip code verification. They also accept debit cards and require authentication with the cardholder’s personal identification number (PIN).

Figure 34. Smart Card Dispensers

Patrons who park in a WMATA lot are required to use a SmarTrip card to exit the parking facility. Fees are collected until midnight or until the facility closes. The card is preloaded with $5 of value and sold for $10 in Metrorail stations with parking lots. Cards can also be purchased from three dispensers at the Metrorail sales office at the Metro Center station.

11.2.1.2 No-Cash Policy The Metrobus system became fully SmarTrip capable in August 2004. By June 2004, WMATA had issued in excess of 500,000 smart cards. Card issuance was handled primarily by three transit store sites, the Internet, tables in stations, and a bank lockbox. The SmarTrip card base increased from 700,000 to 1.2 million between 2004 and 2005. Cards sold using the card dispensers accounted for 80% of the increased sales; store sales dropped to 15% of total sales. Station dispensers sold as many cards in a single year as were sold in the previous 5 years.

11.2.1.3 Reserved Parking The WMATA parking contractor was also operating a monthly reserved parking program for about 5,000 daily users. Each reserved parking patron received a mirror hanger and a monthly payment sticker to display when the patron parked at an assigned reserve space at the designated facility. Patrons paid $90 per month and exited without additional payment. This approach represented potentially missed revenue. Under the new system, customers pay a monthly premium of $45 for reserved parking but must also pay a daily fee when they exit the lot. The reserved parking patron is guaranteed a spot until 10 AM, at which time any unused reserved spaces are opened to the general public. Parking is free on weekends and Federal holidays.

To accommodate the contractor’s reserved parking program, WMATA used their existing web site to host patron enrollment and support internal lot administration. Between the 10th and 15th of the month, a reserve parking permit subscriber’s credit card is charged and a sticker is mailed out for the hang tag. There are approximately 5,000 such subscribers, representing about 10% of the spaces available. Approximately 500 people pay by check. WMATA is considering discontinuing check acceptance. Figure 35 illustrates how the reserve permit system works.

Figure 35. WMATA Reserve Permit Data Flow

11.2.1.4 One-Time Visitors While many lots are at or near capacity daily (90% system wide), spaces remain available. Utilization rates remain fairly consistent through the year, with tourists filling in for local residents who are on vacation. About 50% of the current patrons who buy a SmarTrip card through the dispenser use it only once. Many presumably find the park-and-ride fee of $10 reasonable for the Washington, DC, area. Since WMATA continues to pay over $3 per card for card stock and the card must be handled prior to sale, WMATA is anticipating the introduction of limited-use paper-based contactless cards. One-time visitors often react very negatively to paying $5 just to obtain a zero value card, although this reluctance can often be overcome when the visitor receives an explanation of how to use the card. WMATA is in the process of evaluating limited use (previously called disposable) smart cards to reduce the cost for one-time visitors.

The system experiences 400–500 non-payer transactions per day (≤1%), where the patron does not have a card when arriving at the exit gate. Each non-payer receives a form and payment can be made to a bank lockbox.

11.2.1.5 Conclusions WMATA was in a unique position to move to cashless parking as a result of its substantial investment in contactless smart card technology. Nevertheless, adoption of cashless parking constituted a significant risk to the SmarTrip card program. WMATA’s move to cashless parking has been a success: shrinkage in cash collections is no longer a factor. SmarTrip card distribution through dispensers has resulted in dramatic growth in card ownership and use. Web site applications allow staff and users to manage parking program spaces more efficiently. Table 16 summarizes the situation before and after WMATA implemented this system.

Table 16. Comparison of Parking Payment before and after Smart Card Implementation Early 2004 System Late 2004 System (Cash and Smart Cards) (Smart Cards Only)

 Fees collected in cash on exit by the contractor  SmarTrip required for payment at all Metro at parking kiosks parking facilities  Kiosks open weekdays from 2–10 PM  Parking fees collected from 9 AM to closing each business day  Reserved parking spaces paid monthly in advance; $90 for a hang tag and  Card dispensing machines in all stations with monthly sticker; space reserved until 10 AM parking and at Metro Center station weekdays  Contract employees assist customers and  No exit fee collected from reserved parkers monitor transaction process at SmarTrip readers (but do not handle cash)  More than 95% of all patrons registered their cards to insure replacement if lost or stolen  Reserved parking fee reduced to $45/month, but now exit fee must be paid (daily $3.50 to $4.00 fee upon exit)  Registration dropped to 55% of card base

Cashier Lane

Contract employees assist customers and monitor transaction process.

Express SmarTrip Lane

11.2.2 Parking Operations in Israel Israel has implemented a nationwide parking application called EasyPark that uses one card to pay for parking anywhere in the country. Previously, on-street parking in Israel was paid for using a municipal punch card that was available for purchase in local kiosks. EasyPark was an ideal solution for this environment. Drivers simply activate a contactless in-vehicle parking device (card) when they park and display it in the card window (see Figure 36). When they return to the car, they turn off the device. Drivers are no longer required to obtain individual parking punch cards for every city, and they pay only for the exact amount of time parked, whether it is an hour or only 10 minutes. The card includes a built-in screen that displays payments and remaining balances. The EasyPark card is sold in post offices; value reload stations are available in post offices and gas stations. The system is currently fully operational, with 250,000 subscribers using it in 30 different parking zones across the county. (Parking zones can be different areas of a city in which it costs different amounts to park, or time periods, which can be classified as subzones, or even entire cities.) The EasyPark application can manage up to 60,000 parking zones. A total of 30 zones have been assigned to date. In addition, residents use a residential parking permit to park in their neighborhoods. This permit is renewed annually and is automatically updated once the annual fee is received by the parking authority participating in each city/zone. Municipal and private parking lots can participate if they choose. EasyPark’s parent company, OTI, compensates the 30 parking authorities according to usage. OTI EasyPark manages the system for the parking authorities for a negotiated transaction fee. OTI implemented a business model of generating revenues from product sales as well as transaction fees and customer support. This business model shares the risk and success of the project between municipal parking authorities and vendors, reducing the risk for both entities. Figure 36. Easy Park System Components

EasyPark card (left), a hand-held terminal (center), and a loading station.

11.2.2.1 System Characteristics The EasyPark card and the residential parking permit use ISO/IEC 14443-compliant smart card chips. The parking authority needs to acquire only the enforcement reader/printer and loading stations; no other on-street devices are required. The value loading stations are kiosks or POS-type devices deployed in retail locations, gas stations, or postal facilities. They are clearly identified as loading stations and placed strategically throughout each zone. Each parking authority decides on the number and location of the stations. Reloading is accomplished using credit/debit cards. The stations can be outfitted with bill acceptors at the discretion of the parking authority. Over-the-counter attended POS devices could also be used as loading stations. In Israel, however, a totally unattended, cashless system is being used, further reducing cost to the parking authorities.

11.2.2.2 Customer Benefits EasyPark provides customers with the following benefits:  The customer pays only for exact time used.  The device is simple to operate.  There is no need to leave the vehicle to pay for parking or search for coins for a meter.  The system provides a receipt and proof of payment/parking.  The system can be reloaded in convenient retail locations and gas stations using cash or credit or debit cards.

11.2.2.3 Municipality Benefits EasyPark provides the municipality with the following benefits:  The system provides higher income, which is distributed proportionally among parking authorities for actual usage in each city/zone.  Minimal initial investment is required.  EasyPark operates in parallel with other systems.  The prepayment principle provides float.  The system is tamper-proof, reducing losses from meter break-ins.  The system is eco-friendly—there are no pay-and-display tickets or unsightly meters.  Using EasyPark creates a positive, progressive image for the municipality.  A parking monitor can check a larger number of vehicles per shift.

Figure 37. Easy Park System Diagram

12 Relevant Standards and Specifications Numerous standards are relevant to smart card applications and more are created every year. They have various impacts at different levels of a smart card based-system and may deal with physical characteristics, security certifications, transmission protocols, and application loading or design. There are also industry "specifications," which are not "standards," but which play a very important role in smart card applications. Not all application specifications are listed in this section, though some of the important industry-focused applications are included. Standards are voluntary, but are generally adhered to in the interest of achieving conformity and interoperability. A brief synopsis of the various smart card standards and specifications is included in this section. Additional information can be found in the body of work referenced with each smart card standard or specification. ISO/IEC is the worldwide standard-setting body for technology, including plastic cards. These standards set minimums, but also include many options and tend to leave some issues unaddressed. As a result, conformance to ISO standards alone does not necessarily ensure interoperability – nor does it ensure that cards and terminals built to the specifications will interoperate. The main standards that pertain to smart cards are ISO/IEC 7810, ISO/IEC 7816, ISO/IEC 14443, ISO/IEC 15693, ISO/IEC 24727 and ISO/IEC 7501. The following should be noted: 1. Some standards listed below are available free of charge, but many must be purchased. 2. Some standards may not be listed in this section, but could be relevant to a specific application or a specific technique required by an implementation (e.g., standardized format of biometric information). This section contains a list of standards and specifications relating to this module. A more complete listing of standards and specifications, with descriptions of each, can be found in Module 1.

12.1 Standards Relevant to Smart Card Physical Characteristics  ISO/IEC 7810 – Identification Cards – Physical Characteristics  ISO/IEC 7816 – Identification Cards – Integrated Circuit Cards142 12.2 Standards Relevant to Technologies Which Could Be Found on a Smart Card Smart cards often include other technologies in the card body. The following standards apply to common technologies:  Magnetic stripes: ISO/IEC 7811 series, Identification cards – Recording technique  Linear bar codes: ISO/IEC 15416 Information technology – Automatic identification and data capture techniques – Bar code print quality test specification – Linear symbols  PDF417 bar code: ISO/IEC 15438 Information technology – Automatic identification and data capture techniques – PDF417 bar code symbology specification  Optical memory cards: ISO/IEC 11693 Identification cards – Optical memory cards; ISO/IEC 11694 Identification cards – Optical memory cards - linear recording method

142 Source: http://www.iso.org

12.3 Standards and Specifications Relevant to Technologies Related to the Card Interface  ISO/IEC 7816 Series – Identification Cards – Integrated Circuit(s) Cards with Contacts  ISO/IEC 14443 – Contactless Integrated Circuit Cards – Proximity Cards 12.4 Standards and Specifications Relevant to the Card Commands and Application Data Structures  ISO/IEC 7816 Series – Identification Cards – Integrated Circuit(s) Cards with Contacts  GlobalPlatform143  Java Card144 12.5 Standards and Specifications Relevant to Issuers or Specific Industry Sectors  ISO/IEC 7812 Series, Identification Cards – Identification of Issuers  ISO/IEC 7813, Identification Cards – Financial Transaction Cards  ISO/IEC 7816 Series, Identification Cards – Integrated Circuit(s) Cards with Contacts  ISO/IEC 8583 – Financial Transaction Card Originated Messages – Interchange Message Specifications  ISO/IEC 9992 – Financial Transaction Cards – Messages between the Integrated Circuit Card and the Card Accepting Device  ISO/IEC 24014-1 - Public Transport - Interoperable Fare Management System - Architecture  EMV: Integrated Circuit Card Specifications for Payment Systems145  Common Electronic Purse Specification (CEPS)  CEN EN 1546 – Identification card systems. Inter-sector electronic purse  APTA Contactless Fare Media System Standard  Integrated Transport Smartcard Organization (ITSO)  Verband Deutscher Verkehrsunternehmen (VDV)  Open Standard for Public Transport (OSPT) CIPURSE  ANSI INCITS 410-2006 – Identification Cards – Limited Use (LU), Proximity Integrated Circuit Card (PICC)

143 GlobalPlatform specifications are available at http://www.globalplatform.org/specifications.asp 144 Java Card specifications are available at http://java.sun.com/javacard/3.0.1/specs.jsp 145 EMV specifications can be found at http://www.emvco.com.

13 References American Express ExpressPay, http://www.americanexpress.com/expresspay American Public Transportation Association web site, http://www.apta.com/ Accepting Contactless Payments: A Merchant Guide, Smart Card Alliance Contactless and Mobile Payments Council white paper, July 2007, http://www.smartcardalliance.org APTA Asia Fare Collection Study Mission, Ging Ging Fernandez, Booz Allen Hamilton, presentation, 2009 Payments Councils Summit, February 24, 2009 APTA Manual of Standards and Recommended Practices for Universal Transit Fare Cards, http://www.aptastandards.com/PublishedDocuments/PublishedStandards/UTFS/tabid/191/Default .aspx Authentication in an Internet Banking Environment, Federal Financial Institutions Examination Council, October 2005, http://www.ffiec.gov/pdf/authentication_guidance.pdf Banking Payments Pilot: MTA New York City Transit, Steve Frazzini, NYC Transit, presentation, 2008 Payments Councils Summit, February 28, 2008 Barclaycard OnePulse card web site, http://www.barclaycard-onepulse.co.uk Calypso Networks Association web site, http://www.calypsonet-asso.org/index.php Card Payments Roadmap in the U.S.: How Will EMV and Contactless Impact the Future Payments Infrastructure?, Smart Card Alliance white paper, February 2011 Co-Branded Multi-Application Contactless Cards for Transit and Financial Payment, Smart Card Alliance Transportation Council white paper, February 2008, http://www.smartcardalliance.org Common Electronic Purse Specification (CEP), http://www.irisa.fr/vertecs/Equipe/Rusu/FME02/functionalrequirements6-3.pdf Contactless & Mobile Payments, Sandy Thaw, Visa presentation, 2009 Payments Councils Summit, February 24, 2009 Contactless Payments: Frequently Asked Questions, Smart Card Alliance Contactless and Mobile Payments Council publication, February 2007, http://www.smartcardalliance.org Discover, http://www.discovernetwork.com/discovernetwork/discovernetwork.html Dynamic Passcode Authentication: Overview Guide, Visa publication, http://www.visaeurope.com/documents/aboutvisa/dynamicpasscodeauthentication.pdf?d=070207 Electronic Fare the Future for UTA, UTA press release, January 2, 2009 The Electronic Purse, by John Wenninger and David Laster, Federal Reserve Bank of New York, April 1995 EMV in 10 Minutes, Guy Berg, Datacard Group, presentation, “EMV for Merchants and Merchant Acquirers: U.S. Migration Considerations,” Smart Card Alliance webinar, October 6, 2011, http://www.smartcardalliance.org/pages/activities-events-emv-for-merchants-and-acquirers- webinar EMV 101, Guy Berg, Datacard Group, presentation, “EMV Roadmap Implementation Options,” Smart Card Alliance workshop, May 2, 2011 EMVCO web site, http://www.emvco.com EMVCo: Creating Global Standards for Proximity Payments, Brian Byrne (EMVCo) presentation, Smart Card Alliance Annual Conference, May 18, 2010

EMVCo Common Contactless Terminal Roadmap, EMVCo General Bulletin No. 43, First Edition, November 2009, November 2009, http://www.emvco.com/news.aspx?id=46 End-to-End Encryption and Chip Cards in the U.S. Payments Industry, Smart Card Alliance Contactless and Mobile Payments Council position paper, September 2009, http://www.smartcardalliance.org Evolution of E-payments in Public Transport–Singapore's Experience, Silvester Prakasam, LTA, Journeys, Nov. 2009, http://www.lta.gov.sg/corp_info/doc/Singapore_Saikou_080901.pdf Fraud – The Facts 2011, Financial Fraud Action UK, 2011, UK Cards Association, http://www.financialfraudaction.org.uk/Fraud-the-Facts-2011.asp Fraud in the U.S. Payments Industry: Fraud Mitigation and Prevention Measures in Use and Chip Card Technology Impact on Fraud, Smart Card Alliance Contactless and Mobile Payments Council white paper, October 2009, http://www.smartcardalliance.org FTC: ID theft again tops consumer complaints, PC World Australia, March 9, 2011, http://www.pcworld.idg.com.au/article/379120/ftc_id_theft_again_tops_consumer_complaints/ A Guide to EMV, Version 1.0, EMVCo white paper, May 2011, http://www.emvco.com/best_practices.aspx?id=217 Hong Kong Octopus Card web site, http://www.octopuscards.com/enindex.jsp International Organization for Standardization web site, http://www.iso.org Intelligent Transportation Society of America, http://www.itsa.org/ International Parking Institute, http://www.new.parking.org/ Issuer and Merchant Best Practices: Promoting Contactless Payments Usage and Acceptance, Smart Card Alliance Contactless and Mobile Payments Council white paper, July 2009, http://www.smartcardalliance.org ITSO web site, http://www.itso.org.uk/ JCB, http://www.jcbusa.com/ MasterCard PayPass, http://www.mastercard.com/us/personal/en/aboutourcards/paypass/index.html, http://www.paypass.com/performance_insights.html The Mobile Payments and NFC Landscape: A U.S. Perspective, Smart Card Alliance Payments Council white paper, September 2011, http://www.smartcardalliance.org/pages/publications-the- mobile-payments-and-nfc-landscape-a-us-perspective National Authentication Framework Fact Sheet, Infocomm Development Authority of Singapore, January 2011, http://www.ida.gov.sg/doc/Infrastructure/Infrastructure_Level2/20090204132331/NAF_Factsheet. pdf National Parking Association, http://www.npapark.org/ NFC and Transit, Smart Card Alliance Transportation Council white paper, February 2012, http://www.smartcardalliance.org/pages/activities-councils-transportation OneSMART Authentication, MasterCard, https://mol.mastercard.net/mol/molbe/public/login/ebusiness/smart_cards/one_smart_card/biz_op portunity/cap/index.jsp Open Payment Standards Approach to Fare Payment: NYCT Pilot Phase II Update, Steve Frazzini, MTA NYC Transit, presentation, Smart Card Alliance Payments Summit 2009, February 25, 2009

Over One Million Barclays Customers Bank Online with Gemalto's Solution in the UK, Gemalto press release, July 9, 2008 PayPass Update: MasterCard PayPass Consumer Benchmark Survey, 2008, Burt Wilhelm presentation, 2009 Payments Councils Summit, February 25, 2009 Resolution: Preventing Card Fraud in a mature EMV Environment, Doc EPC424-10, European Payments Council, January 2011, http://www.europeanpaymentscouncil.eu/knowledge_bank_download.cfm?file=EPC424- 10%20Approved%20Resolution%20on%20Mature%20EMV%20Fraud%20Prevention.pdf Serving Unbanked Consumers in the Transit Industry with Prepaid Cards, Smart Card Alliance Transportation Council white paper, June 2008, http://www.smartcardalliance.org Single Euro Payments Area: Seventh progress report – Beyond Theory into Practice, European Central Bank, October 2010, http://www.ecb.int/pub/pdf/other/singleeuropaymentsarea201010en.pdf Smart Card Handbook, Wolfgang Rankl and Wolfgang Effing, Fourth Edition, John Wiley and Sons, Ltd., 2010 Smart Card Standards 101, William Gostkowski presentation, CTST 2009 Smart Card Technology and Payments Applications Workshop, May 4, 2009 Smart Cards and Parking, Smart Card Alliance Transportation Council white paper, January 2006, http://www.smartcardalliance.org Smart Cards and Payments: Technology, Standards and Transaction, Gilles Lisimaque presentation, Smart Card Alliance webinar, November 18, 2008 Smartcard Interoperability Issues for the Transit Industry, Transit Cooperative Research Program, TCRP Report 115, 2006, http://onlinepubs.trb.org/onlinepubs/tcrp/tcrp_rpt_115.pdf 'Smart' parking meters catching on across U.S., USA Today, February 24, 2009 Supplement to Authentication in an Internet Banking Environment, Federal Financial Institutions Examination Council, June 2011, http://www.fdic.gov/news/news/press/2011/pr11111a.pdf Transit and Contactless Financial Payments: New Opportunities for Collaboration and Convergence, Smart Card Alliance Transportation Council white paper, October 2006, http://www.smartcardalliance.org Transit and Contactless Open Payments: An Emerging Approach for Fare Collection, Smart Card Alliance Transportation Council white paper, November 2011, http://www.smartcardalliance.org Transit and Retail Payment: Opportunities for Collaboration and Convergence, Smart Card Alliance Transportation Council white paper, October 2003, http://www.smartcardalliance.org Transit Payment System Security, Smart Card Alliance white paper, August 2008, http://www.smartcardalliance.org TransLink Program Update, David Weir, Metropolitan Transportation Commission, presentation, 2009 Payments Councils Summit, February 25, 2009 UTA Electronic Fare Collection System: Development Progress Report, Craig Roberts, UTA, presentation, 2009 Payments Councils Summit, February 25, 2009 Verband Deutscher Verkehrsunternehmen (Association of German Transport Undertakings – VDV) web site, http://www.vdv.de/en/index.html.

Visa payWave, http://usa.visa.com/personal/cards/paywave/index.html, http://usa.visa.com/personal/cards/paywave/issuers_offering.html, http://usa.visa.com/paywave- merchants/ Visa TAP Co-Branded Card, Jane Matsumoto, LACMTA, presentation, 2009 Payments Councils Summit, February 24, 2009 Washington Metropolitan Transit Authority (WMATA) SmarTrip, http://www.wmata.com/fares/smartrip/ Worldwide EMV Deployment and Adoption, EMVCo publication, http://www.emvco.com/documents/EMVCo_2011_EMV_Deployment_Stats.pdf

14 Acknowledgements This document was developed by the Smart Card Alliance for the Certified Smart Card Industry Professional/Payments (CSCIP/P) program. Publication of this document by the Smart Card Alliance does not imply the endorsement of any of the member organizations of the Alliance. The Smart Card Alliance thanks the following members for contributing content for this CSCIP module:  Guy Berg, MasterCard, Section 4, EMV  Peter Comps, LTK Engineering Services, Section 10.1.2, Smart Card Use in Public Transit  David deKozan, Cubic, Section 10.1 Transit and Section 11.1 Sample Transit Smart Card Payment Models  Willy Dommen, Accenture, Section 2, Smart Card Market Drivers and Benefits for Payments and Financial Transactions  Gilles Lisimaque, Identification Technology Partners, Section 8, E-purse and Stored Value Cards  Joshua Martiesian, MTA New York City Transit, Section 10.1.2, Smart Card Use in Public Transit  Timothy Weisenberger, U.S. Department of Transportation/Volpe Center, Section 10.1.3, Transit Standards, Specifications and Guidelines The Smart Card Alliance thanks the following individuals and organizations for their review of the CSCIP module content:  Deborah Baxley, Capgemini  Guy Berg, MasterCard  Brett Chemaly, Discover  David deKozan, Cubic  Willy Dommen, Accenture  Greg Garback, WMATA  Simon Hurry, Visa, Inc.  Ken Indorf, CardLogix  Jerry Kane, SEPTA  Gilles Lisimaque, Identification Technology Partners  Josh Martiesian, MTA New York City Transit  John Rego, OTI America The Smart Card Alliance wishes to thank the many current and past members of the Smart Card Alliance Councils and Task Forces who contributed to the development of the white papers and reference material that was used to create this module. About LEAP and the CSCIP Program The Smart Card Alliance Leadership, Education and Advancement Program (LEAP) was formed to: offer a new individual members-only organization for smart card professional; advance education and professional development for individuals working in the smart card industry; manage and confer, based on a standardized body-of-knowledge examination, the Certified Smart Card Industry Professional (CSCIP) designation. LEAP members who wish to achieve certification as experts in smart card technology may do so at any time. Certification requires that LEAP members meet specific educational and professional criteria prior to acceptance into the certification program. A series of educational modules forming the CSCIP certification body of knowledge has been developed by leading smart card industry professionals and is updated regularly. These

educational modules prepare applicants for the multi-part CSCIP exam administered by the Smart Card Alliance. The exam requires demonstrated proficiency in a broad body of industry knowledge, as opposed to expertise in specialized smart card disciplines. Applicants must receive a passing grade on all parts of the exam to receive the CSCIP certification. LEAP membership in good standing is required to sustain the certification, and documentation of a required level of continuing education activities must be submitted every three years for CSCIP re-certification. Additional information on LEAP and the CSCIP accreditation program can be found at http://www.smartcardalliance.org.

Trademark Notice All registered trademarks, trademarks, or service marks are the property of their respective owners.