Hi, Dan! Can you share a bit about your professional journey in the payments industry?
I got my start a little over five years ago. Initially, I drowned in information. I’d had a background in middle management and coordinating budgets but knew nothing about payments.
On my first projects, I would set up workshops and projects to manage our longer strategy engagements. Lots of note-taking and being a fly on the wall. I was exposed to these dense and passionate conversations about payments. The people I work with are payments lifers. They know their history and why things are the way that they are. The only reason I feel confident in this space is because of how much exposure I got through RPGC conversations and because I was gifted the opportunity to voice my immature opinion, fail, and then get clear explanations on what I wasn’t considering.
Beyond client-specific deliverables, I spend a lot of time trying to understand the payments ecosystem. I wanted to know why a $50 million merchant would have a more sophisticated environment than a $50 billion merchant (and it does happen!). Our payments orchestration whitepaper was born from a desire to understand why a merchant wouldn’t just have a single PSP relationship and call it a day. Thanks to those questions I had to confront the complexity of token fragmentation and authentication.
Can you tell us more about RPGC and your role at it?
Retail Payments Global Consulting Group is a boutique advisory firm focused on all-things payments. We like to equate payments to music. Just playing the notes doesn’t make someone a musician. A musician’s got to consider tone, spacing, phrasing, and more. For us, that’s fraud mitigation, KYC/AML, and payment architecture. That’s why we’ve got over forty consultants in our network spanning the globe across various subject matters. All of our consultants, except for me, have been experts in their respective specialties for over ten years each. I’m very fortunate to watch them work.
I do manage projects and perform competitive analyses, but my primary responsibility is working with our network and playing matchmaker between client and consultant.
What is network tokenization and why is it important?
All payment token standards are proprietary and EMVCo’s network token framework is no different. EMVCo’s owners are all the international card schemes, and they have a vested interest in maintaining credit cards as the dominant e-commerce payment method. For the company line on what network tokenization is, EMVCo does have a decent FAQ on page one.
Each card scheme has its own implementation of network tokenization and issuers contract with certified Token Service Providers (TSPs) that directly contract with issuers to maintain and operate the token vault, issue and provision network tokens and apply token domain restriction controls (e.g. a token provisioned for contactless transactions can’t be used for e-commerce transactions). Using network tokens, the merchant never sees the PAN and never risks capturing the PAN.
Network tokens carry some serious benefits. There’s no PCI compliance to consider on those transactions. When a customer replaces the PAN underlying a network token, there’s no need to perform an account update or ask the customer to enter their new credentials. Instead, the token updates automatically because it’s provisioned by the TSP with that direct link to the issuer. It’s a major argument for why a recurring merchant like Netflix has direct connections into TSPs through Visa. In several markets, the use of network tokens has led to increased approval rates on e-commerce transactions.
So What’s the Catch?
There are a few problems, but they’re considerable. Version 1 of network tokens were not designed to be used for e-commerce transactions. They were designed to protect data in transit, but not for handling when data is at rest with the TSP or at a merchant. If a merchant has a network token and a customer inquires about their guest checkout transaction but lost the receipt, how can the merchant service the call? There are issuers that have been resistant to integrating network tokens, which has led to considerable approval rate dips on an issuer by issuer basis, meaning routing logic is still required to determine whether or not a network token is the best means of getting a transaction approval. Lastly, network tokens only work for payment card transactions using the card scheme rails.
Other payment methods or card schemes like PIN-debit cards here in the U.S. can’t use EMVCo network tokenization. Lastly, network tokenization asks for everyone to make updates to their ISO 8583 protocols, a messaging format designed for point-of-sale and ATM transactions, not e-commerce. Banking is migrating to a newer messaging format, for PSD2 and open banking, ISO20022 uses more modern UML formatted objects… which says a lot about how quickly the finance industry moves.
While a bit dated, Susan Pandy and Marianne Crowe of the Boston Fed have one of my favorite primers on network tokenization (dated 2018).
What is the Industry Roadmap for Network Tokenization?
The comment period for the EMVCo 2.2 specification just finished in September 2020. It refines some new concepts that are integral for portability such as the concept of Payment Tokenization Aggregators who can enable multiple parties to share privileges on initiating a payment transaction on a payment token. Because those changes were more aesthetic than the material from the 2.1 framework, I see it as a signal that onboarding these solutions is now the priority, and it’s now less about defining what network tokenization should do.
Processors, fintechs, and acquirers that intend on handling network tokens need to develop and certify their token programs through EMVCo owner certifications such as Visa Token Services or Mastercard Digital Enablement Services. They also need to update their ISO 8583 message formats to add new fields. A couple of fields that prominently stand out to me are:
- Payment Account Reference. Since each network token is unique for each transaction, network tokens need a number to tie all the possible transactions back to the same payment card. The Payment Account Reference can’t be used to initiate network token transactions on its own.
- Token Requestor ID. A token requestor is the entity that procures the network token from the token service provider. Visa token requestors are a part of the Visa Token Services program. Mastercard has Mastercard Digital Enablement Services for the same role. Token requestors are the ones who implement the card scheme-specific token APIs and are the ones who register and comply with TSP requirements. Netflix is a token requestor and has its own Token_Requestor_ID, but they’re a wild exception to the rule. Most token requestors are PSPs and fintechs.
How will e-commerce evolve over the next few years, especially when it comes to securing and authenticating payments?
EMVCo is driving the industry towards Secure Remote Commerce, or as you may have seen “Click to Pay.” Using 3D-Secure 2 to authenticate the cardholder and provisioning a network token back to the merchant, Click to Pay has been sold as the means to simplify the checkout page in a secure manner through a one-click process. But, for Click to Pay to work seamlessly, 3D-Secure and network tokens need to meet the same seamless sales pitch.
For authentication, Strong Customer Authentication is driving a lot of progress, albeit haphazardly. I personally have a lot of interest in the developments from the FIDO Alliance around how customers can be authenticated through behavioral biometrics as proof of inherence without any Personal information leaving the secure element of a smartphone. As for securing payments, we are already seeing the tokenization of tokens. A merchant’s ERP or CRM doesn’t want to or need to handle multiple token types depending on the payment method, processor, or card type a customer uses. Each of these different formats already needs to get standardized for back-office analysis anyways.
History now repeats itself. PSP tokens locked merchants into specific ecosystems and restricted them from pursuing multi-acquiring strategies. While network tokens provide more value than processor tokens, they still give PSPs the means to lock customers into their service since a payment token transaction still requires the same token requestor ID to initiate. Enterprise merchants are going to continue to find ways to subvert such lock-in to maintain resiliency and enter markets that their providers don’t service.
How would you suggest that merchants should implement Network Tokenization and what problems do you think it will solve?
I wouldn’t advise that any other merchant become a token requester as Netflix did. But merchants do need to tokenize and they do need a common token format to pass through the rest of their stack, regardless of issuer or payment method. This is where I think payment orchestration provides a means forward. When possible, the merchant should still capture and store the PAN (like any other PCI token) and provide a universal token ID back to the merchant for all the other reasons why a payment credential is linked to a customer account.