Portals & Rails
October 20, 2014
Let's Talk Tokens, Part III: What Problem Does Tokenization Solve?
Portals and Rails recently embarked on a series of posts on tokenization. In the first installment, we defined tokenization and distinguished between a merchant-centric enterprise tokenization solution and payment tokens generated as an issuer-centric end-to-end solution. In the second installment, we examined several different attributes of the issuer-centric end-to-end token initiatives currently under way and considered their impact on mitigating risk. In this post, we examine the shortcomings of end-to-end token initiatives and question if they are really a coup in mitigating risks in today's environment.
The goal of payment tokenization is to substitute sensitive data—such as account numbers, expiration dates, and security codes—that criminals can use to extract monetary value with surrogate values that lack monetary value. In light of the number and depth of recent data breaches, tokenization seems like a grand idea—let's get data that fraudsters can use out of the payment transaction flow and the merchants' systems.
But current uses for these end-to-end initiatives are limited to card-on-file transactions for in-app or e-commerce payments and mobile proximity payments. I know you have to start somewhere but, in the near future, only a small percentage of transactions will use tokenization. These end-to-end initiatives are solid solutions, but are currently extremely limited. Thus, there will be a continued need for the industry to use a variety of methods to fight fraud, including the merchant-centric enterprise tokenization solutions the first installment discussed.
And isn't the point of the significant EMV investment currently under way to mitigate risks associated with counterfeit cards using compromised card data? In other words, it should render compromised card data useless. But I am hearing the EMV naysayers claiming that, in an EMV world, data compromises will still take place and, while fraudsters may not be able to counterfeit cards, they can still use that data to shop on the Internet.
Those naysayers are correct.
But let's circle back to the use cases for the current issuer-centric end-to-end token initiatives. Is tokenizing payment data for card-on-file and mobile proximity payments really going to have a material impact on preventing card-not-present fraud? Are these tokenization efforts really the best solution for this challenge? It could be many years before we regularly use our mobile phones for proximity payments. I am confident that we will be using chip-enabled cards for a significant number of transactions within two to three years. Would it be wiser to rely on solutions that leverage the chip or other security features of cards? Or maybe it's time we realize that cards weren't designed for card-not-present uses and place a higher priority on the broader adoption of existing and emerging non-card-based payment solutions in a multi-layered security approach.
Unfortunately, I do not have the answers. But these questions and topics will certainly be discussed during the upcoming Securing Remote Payments conference that the Retail Payments Risk Forum and the Secure Remote Payment Council is hosting. If you are interested in attending, please reach out to us. We will be in touch with more details.
In the next installment in this series, we'll look at new security and operational risks introduced with these token initiatives.
By Douglas A. King, payments risk expert in the Retail Payments Risk Forum at the Atlanta Fed
October 14, 2014
Mobile Biometrics: Ready or Not, Here They Come
Apple's recent announcement about the release of its mobile wallet app—called Apple Pay—energized the mobile payments community. One reason for the spike of interest is Apple Pay's use of fingerprint biometrics as an additional layer of security in validating customers and their transactions. What may have gotten a little a little lost in the chatter that followed this announcement was another, related announcement. As reported in a September 19 FinExtra story, MasterCard (MC) announced it had completed a pilot project that used a combination of facial and voice recognition on a smartphone. MC said that the trial program—which involved MC employees around the globe conducting 14,000 transactions—had a successful validation rate of 98 percent.
The Apple and MC announcements together certainly show that the future of the additional security options on smartphones looks promising. As a recent post noted, consumer research has consistently found that consumers' largest concern about using mobile phones for financial transactions is security. But are biometric technologies ready for prime time? Will their application in the payments ecosystem really give payment providers more confidence that the person they are dealing with is not an imposter?
The latest generations of Apple and Android smartphones are equipped with fingerprint scanners, cameras, and microphones, which allow for the use of fingerprint, voice, and facial recognition. But limitations exist for each of the techniques. The Apple and Android fingerprint readers, for example, were compromised within days of their initial release. And facial and voice recognition applications work best in controlled conditions of lighting and with limited background noise—an unlikely environment for a smartphone user on the go.
But security experts agree that additional customer authentication methodologies—beyond the common user ID and password entry fields—increase the overall authenticity of transactions. Numerous companies are continuing to focus their research and development efforts on improving the reliability and use of their authentication products. So while there is no "one size fits all" authentication solution over the weak and easily compromised ID-and-password method, these biometric methods represent a step forward, and are likely to improve over time.
The Retail Payments Risk Forum is taking a close look at biometrics technology and its impact on the payments system. We are working on a paper assessing biometrics and authentication methodologies that will probably be released by the end of the year. We're planning a forum to be held this upcoming spring on mobile authentication technologies. And we're continuing to write posts on the topic in Portals and Rails.
Please feel free to contact us with your suggestions on biometric issues you would like to see us address in our continuing efforts.
October 06, 2014
Starting Off on the Right Note with Mobile Enrollment
In Rogers and Hammerstein’s Sound of Music, the classic song “Do-Re-Mi” begins “Let's start at the very beginning / A very good place to start...” Such a suggestion is essential in ensuring that the person enrolling in a payments system is, in fact, who he or she claims to be. The USA Patriot Act requires financial institutions (FIs) to develop a formal customer identification program that validates the customer when the account is opened. This program must specify the documentation that is used for authentication.
However, once the account is open, FIs have greater latitude in their procedures for identifying customers when the FIs handle account access requests, such as when a customer requests a change of address or enrolls in a third-party program that uses a card that the FI has issued to the customer. At that stage, it’s up to an FI’s own risk-management policies as to what documentation to require.
This situation can be risky. For example, let’s look at what happens when a customer wants to add a payment card to a mobile wallet that a third party operates. When the customer adds the card—enrolls with the third party—how can the FI that issued the card know that not only the payment card being added but also the mobile phone itself belongs to the right individual? How can the issuer efficiently and effectively ensure that the payment card information being loaded on a phone hasn’t been stolen? Adding any sort of verification process increases the friction of the experience and can result in the legitimate user abandoning the process.
Most mobile wallet operators use several techniques to validate that both the mobile phone with the wallet and the payment card belong to the rightful customer. (These operators send a request to the issuing FI as part of their enrollment process.) Some FIs require the operator to have customers submit their payment card information along with their cards’ security code and additional data, such as the last four digits of the social security number. Others may require just the payment card number, expiration date, and card security code, although such a minimal requirement offers little protection against a stolen card being added to a criminal’s phone. Still others require the customer to submit a photo of the payment card taken with their phone to verify possession of the card. If the issuer can obtain some of the phone’s device information, it can increase the level of confidence that the authorized cardholder is using their phone.
Regardless of what process is used, having strong identification controls during the initial enrollment step is essential to a sound risk management program.
By David Lott, a payments risk expert in the Retail Payments Risk Forum at the Atlanta Fed
September 29, 2014
Let's Talk Token, Part II: Distinguishing Attributes
Several weeks ago, Portals and Rails embarked on a series of posts on tokenization. In the first installment, we defined tokenization and distinguished between a merchant-centric enterprise tokenization solution and payment tokens generated as an issuer-centric end-to-end solution. Since writing the first post, payment tokens has jumped front and center in the payments community when Apple introduced Apple Pay, which uses tokenization. Also, the Mobile Payments Industry Workgroup just released a detailed white paper recounting their recent meeting on the current tokenization landscape in the United States.
In today's installment, we look at some distinguishing attributes of the end-to-end token initiatives currently under way and consider their impact on mitigating risk in payments transactions.
- Token format: Common ground exists in the payments industry in terms of the token format. The end-to-end token solution relies on the creation of a token, known as a device account number (DAN), to initiate a payment in place of the original primary account number (PAN). To mitigate operational risks and make use of existing messaging rules and applications associated with the payment transaction, it is imperative that the format of the DAN preserves the format structure of the PAN. This means that DAN generation should be as random as possible, even while preserving the original PAN format structures to maintain basic card or account validation rules associated with the PAN.
- Token type: Payment tokens can be dynamic or static. Dynamic tokens are valid either for a single transaction or for a limited number of transactions occurring in a very short time. By the time a fraudster intercepts a dynamic token, it has likely already expired, so the fraudster can’t use it. However, there is a slight down side to dynamic tokens—they can work against loyalty programs as well as some back-end fraud detection systems. Because each transaction has a different DAN, merchants and processors cannot consolidate multiple transaction information for an individual cardholder.
On the other hand, static tokens are multi-use, so they allow merchants to connect the token user with past transactions. But given their multi-use nature, they are not as secure as dynamic tokens. For additional security, each transaction with a static token can include an additional element: a uniquely generated cryptogram.
- Device coverage: Tokens can be created and stored either on a secure element on a mobile phone or in a cloud. Much industry discussion focuses on which approach is more secure, but the approach also has an impact on device access to the token. Storing a token only on secure elements limits tokens to mobile phones, a situation that does not address the significant volume of card-not-present payments that consumers conduct on computers and other devices. Alternatively, storing a token in a cloud would allow any connected device (mobile, tablet, laptop, or computer) to access the token, so all e-commerce transactions would be covered.
- Token service provider: A number of parties can play the critical provider role. The provider is ultimately responsible for generating and issuing the DAN, maintaining the DAN vault, and mapping the DAN to the PAN for presentment to the issuer that ultimately authorizes the transaction. A network, issuer, processor, or another third-party provider can perform this role. We can make a case for any of these parties to play the role, but the critical risk mitigation factor to note is that the merchant should never see the PAN, thereby preventing a breach of payment card data within their systems.
To date, a standards body controlled by the largest global card networks and a company representing the largest global banks has driven most of the payment tokenization standardization efforts. Although these organizations have advocated for public discussions and input in an open environment, some critics argue that the management of standards development should be left to an open-standards body such as X9 or ISO. Tokenization efforts and standards will continue to evolve as tokenization may play a critical role in mitigating payment risk in the future. Still, security challenges will remain even with its adoption. In the next installment of this tokenization series, we will examine risks that that a tokenized payments environment won't resolve, and risks that will be all new.
By Douglas A. King, payments risk expert in the Retail Payments Risk Forum at the Atlanta Fed