About


Take On Payments, a blog sponsored by the Retail Payments Risk Forum of the Federal Reserve Bank of Atlanta, is intended to foster dialogue on emerging risks in retail payment systems and enhance collaborative efforts to improve risk detection and mitigation. We encourage your active participation in Take on Payments and look forward to collaborating with you.

Take On Payments

« New ACH Return Rate Threshold on the Horizon | Main | Starting Off on the Right Note with Mobile Enrollment »

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


September 29, 2014 in authentication , fraud , mobile payments | Permalink

TrackBack

TrackBack URL for this entry:
https://www.typepad.com/services/trackback/6a01053688c61a970c01b7c6e9606d970b

Listed below are links to blogs that reference Let's Talk Token, Part II: Distinguishing Attributes :

Comments

Post a comment

Comments are moderated and will not appear until the moderator has approved them.

If you have a TypeKey or TypePad account, please Sign in

Google Search



Recent Posts


Archives


Categories


Powered by TypePad