Glenbrook’s Russ Jones returns with George Peabody and Yvette Bohanan on this episode of Payments on Fire® to discuss tokenization – a substitution of a high value primary account number with a digit that, in many cases, looks just like the original PAN, but isn’t.

Tune in as they break down how tokenization works and the security it provides (amidst numerous cooking metaphors). 

 

 

George Peabody:

Welcome to Payments on Fire, a podcast from Glenbrook Partners about the payments industry, how it works, and trends in its evolution. I’m George Peabody, co-host of Payments on Fire, and I’m here with Yvette Bohanan, who is always joining me on Payments on Fire. Yvette, great to see you and hear you.

Yvette Bohanan:

Great to see and hear you, George. Always lovely to be here.

George Peabody:

We are, again, joined by Russ Jones, who is the squadron leader, as I said last time, of our education program. Russ has a remarkable ability to bring clarity to what is, well, we all know if you’re in the payments industry for, I don’t care actually how many years, it’s still a complex industry with distinctions that have everything to do with security, with profitability. Today we’re talking about a tool set that really applies to the card system, in a way, to make the card system more secure. The card system invented decades ago is now operating online all the time, and it’s sharing account information, card information that needs to be devalued when it’s running over the network.

George Peabody:

We’ve got a couple of techniques to do that. One is encryption, but we’re talking today with Russ and Yvette about tokenization, which is a substitution of that high value primary account number with a digit that looks just like, in many cases, the original PAN, but isn’t. So we’re putting low value data, now, out on the network. There are a couple of flavors of tokenization, and we’re asking Russ as chef of this podcast, to talk about those flavor differentials, and where one tastes better than the other. So Russ, let’s go.

Yvette Bohanan:

So wait a minute. So George, to keep with this culinary theme, because we are foodies at Glenbrook, the mother sauce, the mother recipe, Russ, we’re going to start there. We’re going to start with this is EMVCo token.

George Peabody:

So EMVCo tokenization is one of the flavors we’re talking about.

Russ Jones:

Well, there’s just one flavor, maybe two flavors. A lot of merchants have been tokenizing card credentials for a long time. That’s referred to as merchant tokenization. We’re not really talking about that. We’re talking about tokenization that, in the card system, happens on the issuer side of the ecosystem.

George Peabody:

Great.

Russ Jones:

So it’s technically EMVCo tokenization. At Glenbrook, we like to call it issuer tokenization, because the issuer is in charge of it. Visa and MasterCard often call it network tokenization because when they’re involved in it, they think of themselves as networks. So think of them as a synonym. A bunch of synonyms actually. EMVCo tokenization, network tokenization, issuer tokenization.

Russ Jones:

What it is clearly not is merchant tokenization. The decision to do this and how it’s done is under control of the issuer. So that’s just what it’s called. The way it was defined, and the reason it’s called EMVCo tokenization formally, is EMVCo is the joint venture entity owned by all the major international card networks that establishes common technical standards across the card system, that cut across the networks.

Russ Jones:

So when you think about how data on a magnetic stripe is formatted, MasterCard does it the same way as Visa. That’s because there are common technical standards, and the card system and EMVCo is oftentimes involved in specifying these standards.

Yvette Bohanan:

Chip and pin, another example.

Russ Jones:

Yeah. Yeah. The way chip and pin works is a good example. The way 3D secure works in the card system is a good example of this. The way your tokenization model works as well. So this model, as you were saying, George, if they were to substitute a dummy number for the card number, which you refer to as the PAN, the primary account number. I know you like PAN because you’re an industry insider.

George Peabody:

Oh, sorry about that. I was trying to carry on that cooking metaphor that we started with.

Russ Jones:

Yeah, okay, okay. I’ll go along with that.

Yvette Bohanan:

Different kind of pan, but, hey, we’ll take it.

Russ Jones:

Yeah. So it’s up to the issuer how they want to do this. What that this is, is how do they want that substitution to have? So there will be tokens that are created that are dummy numbers that look like PANs or card numbers. Map one to one, a token maps to a PAN. So the token is used to buy things, make payments, and it’s backwards compatible with everything because it looks like a card number.

Russ Jones:

But it has these super characteristics that a generic card number doesn’t have. In general, these tokens are very tightly aligned with the issuer. For example, when you put your card in the Apple Pay wallet, as an example, provision it into the wallet. There’s two stakeholders involved in that process. One by EMVCo terminology, one is called a token requester, which is what the Apple Wallet is.

Russ Jones:

The other one is a token service provider, who is a type of processor. The token service provider manages the mapping, will turn a PAN into a token, will turn a token back into a PAN, and will allow requesters and issuers to do life cycle maintenance on that relationship. So they can temporarily pause the mapping, they can turn it off, they can cancel it, they can refresh it, things of that nature. So token requesters, token service providers, that’s the vocabulary of the EMVCo tokenization.

Russ Jones:

So one of the big characteristics of these tokens is they can be usage restrict. Cards typically are not usage restricted. Famous Visa saying as it’s everywhere you want to be. Meaning it works across all use cases and all scenarios for all stakeholders. It turns out there’s lots of examples where there’s substantial benefits to having things not be as free flowing, and be more usage restricted. So that card data that I put into my Apple Wallet is usage restricted so that it can only be used on my device. So it’s very tightly tied.

George Peabody:

So it’s got to come from that specific device. That token is bound to that device, if you will.

Russ Jones:

Yeah, it’s a very tight binding. It’s done using the device ID of the consumer device. So if it’s my smartphone, it’s the device ID of the smartphone, my tablets, the device ID of the tablet, the watch, if the payment data goes into the watch, it’s the device ID of the watch, it’s a very tight binding.

George Peabody:

So let me just be clear there. For all three of those devices, for each device, there is a specific token that’s been bound to that device. All three of those could point to the same underlying card account.

Russ Jones:

So when this creates an extra layer of security, because to use the card in the wallet, I have to authenticate myself to the device. The card through the token is very tightly bound to the device. So if the device was compromised and the tokens were stolen, they couldn’t be used on another device.

Yvette Bohanan:

That’s what people are always asking us in the workshops is how secure is this really?

Russ Jones:

The answer is it’s super secure.

Yvette Bohanan:

It’s not just that it’s bound to the device. So if I lose my phone, through that life cycle management process, they can shut down the token associated with that phone. Then if I find my phone, they could even reprovision and new token, right? Turn it on.

Russ Jones:

Now the other thing, George, you’re, you’re absolutely right. The token is device specific. In that scenario with my tablet, my phone, and my watch, I would’ve three different tokens that all map back to the same card. But what makes it extra secure is that every time you use that static token, there is a dynamic security code that’s generated that goes along with token, that’s called a cryptogram in industry terminology. So the two have to be together. You have to have the token and the cryptogram in order to do authorization requests.

George Peabody:

So that’s really taking the technology and security approach that was really pioneered with the chip and pin model, and now applying it onto smartphones.

Russ Jones:

Well, it’s just a hyper secure sort of architecture. Because you have the authentication to get out the underlying token, the authentication of the person that provisioned the card to get underlying token. You got the dynamic security code that is different on every transaction, and you got the idea that the token is not the real card data. It can be turned off on demand, it can be usage restricted in various ways. So it’s a really super secure sort of thing.

Russ Jones:

You end up with some really good characteristics inside the card system. Because the issuer is involved in provisioning the token through a token service provider into the wallet, you’re going to have less fraud on that card, because there’s been an authentication between the issuer and their customer. The issuer is very comfortable that the person provisioning the card data, the wallet, is their customer. So you have less fraud when it comes time to authorize using a token.

Russ Jones:

The token, because it’s tightly bound to that device and it can’t be used in other scenarios, you have an increased authorization approval rate. Then there’s an added benefit for merchants in that when they’re processing these tokens, the mapping between the token and the real card number is done by the token service provider. So the card data is always current. The token is always current. It never goes stale, because if there’s any change in expiration number or card attributes, that’s done in the cloud and the merchant doesn’t have to be involved in it. So sort of a win-

Yvette Bohanan:

All the account updater stuff that-

Russ Jones:

Yeah, all that account updater sort of fades to the background to a large extent.

George Peabody:

What kind of uptake have we seen with the merchants storing, using tokens to initiate transactions?

Russ Jones:

Well, it’s hard to say. There’s no … The US Department of Commerce doesn’t track this. But Apple alone supports some really phenomenal transaction initiation rights with Apple Pay. If you believe, this was two years ago, they were quoting 1.25 billion Apple Pay transactions per month. If you believe them then, if you think they were being honest with you, that was 5% of all the card payments in the world initiated through Apple Pay. That’s gigantic uptake, I would say.

Russ Jones:

So the thing about this model, George, is that there are a lot of use cases here. I talked about the distinction between a token service provider, the token requester. The token service provider, it could be the issuer themselves do this. They don’t need to involve a third party, or they could hire a processor to do it for them, or they could hire a card company acting as a processor to do it.

Russ Jones:

So a Visa issuer could hire Visa, the processor, to do this, they could also hire IBM to do it for them. It’s not tightly tied to any card network, so to speak. On the requester side, the requester could be a mobile wallet on a device, could be a digital wallet in the cloud, it could be the merchant themselves. There’s lots of scenarios of who the token requesters could be. EMVCo had the foresight, this was in 2013 when they released their specification, they had the foresight to anticipate all these different use cases of where they thought this technology would be used.

Russ Jones:

So the original use case was app and pay at the point of sale. So EMVCo tokenization launched with Apple Pay. Now you would tap your iPhone on a contactless terminal and a token would jump across from your Apple Wallet to the merchant. The merchant would process it as they process any card transaction. At the same time, they also released in-app purchasing so that the token, instead of being used to emulate a contactless card, was simply handed to the app, and the app could use that token data to authorize purchases.

Russ Jones:

So those were the two original use cases. Then later on we saw both Google and Apple introduce the ability for online merchants to accept tokenized transactions. So Google called that Google Pay and Chrome, Apple called it Apple Pay and Safari. But it lets you buy something online, biometrically authenticating yourself, your device. So that was really the third use case.

Russ Jones:

Then we saw the adoption of digital wallet start using tokenization. So things like Visa checkout, pay by click, they pass the card credentials to our online merchant. They’re passing up tokenized credentials. So that was an incremental expansion of tokenization. Then maybe about three years ago, we started to see token service providers release APIs so that merchants themselves could take the card data they have on file, and convert card on file to token on file, and pick up the same attributes that would benefit any tokenized transaction.

Russ Jones:

So the motivation to the merchant to do this, why would they take their card on file information and convert it to tokens? Reduction in fraud, increased authorization approval rate, and global protection against stale data. So there’s some pretty powerful motivation there. So what’s interesting in that use case is the consumers and the customers of these online merchants don’t even see that happening. They’re not even aware that it’s going on. This is purely a back office phenomena.

Russ Jones:

So there’s still a preventing step and what’s going on there is the token service provider is the token service provider, and the merchant becomes the token requester. So just like the Apple Pay wallet was the token requester, now the online merchant is the token requester. Instead of the token being tightly bound to the device ID, the token is tightly bound to the merchant’s ID.

George Peabody:

So if that token came from another source, it’s going to fail.

Russ Jones:

It’s going to fail. Yeah, exactly.

Yvette Bohanan:

The other source being a different merchant identifier.

Russ Jones:

Yeah, a different merchant. So it just couldn’t be used by for any other purpose except by the merchant who provisioned the token to do an authorization request. That was the only permitted use of that token. So the way it actually worked was the merchant as a token requester would call, make an API call to the token service provider to provision that card into tokenization and get back a token for them to put on file.

Russ Jones:

But the subtlety there was they didn’t actually get back the token. They got back a pointer to a token. So it was like indirection within direction. Because the token is the pointer to the real card data, and what the merchants got back was a pointer to the token. So the reason it was done this way was because once again, the token is static, but you want to have a dynamic security code that is unique on every transaction.

Russ Jones:

So when the merchant has their customer’s token on file and they want to do an authorization, they would call out to the token service provider saying basically, “I want a token and a cryptogram a one time cryptogram, and I want to use these two together to do an authorization request.”

Yvette Bohanan:

So here’s the pointer to the token, send me back the token and the cryptogram that I can use for this distinct transaction.

Russ Jones:

Yeah, yeah, that’s exactly how it works. So what’s happened, what’s transpired? That was what the token service provider started exposing these APIs maybe about three or four years ago. So you can imagine Visa is a token service provider, MasterCard is a token service provider, American Express is a token service provider. Their APIs all did the same thing except they were different. In the world of payments, anytime you see things that are similar but different, it’s an opportunity to plug in a gateway.

Russ Jones:

So today there are token gateways, and the merchant now says, “I want to provision this card into tokenization.” The gateway figures out what token service provider, do I need to talk to Visa? Do I need to talk to MasterCard? Do I need to talk to American Express? Do I need to talk to IBM? Do I need to talk to the issuer themselves?

George Peabody:

So the merchant only has one interface to deal with rather than each one.

Russ Jones:

So who are these token gateways? They’re all the mainstream payment service providers. So strive-

Yvette Bohanan:

Sure. They’re definitely in there. .

Russ Jones:

All the companies that merchant would turn to for help to simplify payments. They also get help-

Yvette Bohanan:

There’s a couple that are independent too, like Token X.

Russ Jones:

Yeah. So we like to say, about payment service providers, they all have the same value proposition, which is, payments are hard. We make it easy. They do the same thing in tokens. Tokenization is hard. We make it easy.

Yvette Bohanan:

Exactly. We can reduce this down to a single API in a single call or two. They provided for all those use cases you walked us through. So it’s use case agnostic in a lot of respects too, with the gateway.

Russ Jones:

Well, the gateway is really catering to the merchant who wants to do token on file processing.

Yvette Bohanan:

For the most part, yeah.

Russ Jones:

There’s also a new use case on the horizon, and this is something that Visa and Google are working on. Both of them have been talking about it publicly. Which is to turn the Chrome browser itself into a token requester, so that you could be using Chrome on PC, you could be using Chrome wherever it runs, and the tokens would be managed by the browser. Then when you go to fill out a form, you’re checking out with an online merchant through your browser. You go to fill out a form and you auto fill your card data. If it is, if you have put cards into your auto fill, those will be tokenized credentials that are passed to the merchant.

Yvette Bohanan:

Are they tokenized credentials or are they pointers to-

Russ Jones:

They’re tokenized credentials.

Yvette Bohanan:

They’re the actual tokenized credentials.

Russ Jones:

They’re the actual tokens. So the interesting, the good news about that is the basic token architecture, the EMVCo model underscores and is built around backwards compatibility. So you don’t have to treat tokens any differently than you treat a car. So the generic merchant selling Pez dispensers off of a website thinks they’re putting up a form and collecting card data. What they don’t see is the world evolved and goes forward, they’ll be putting up a form collecting card data, and what will come back will be tokens.

Russ Jones:

What do they do with them? They do what they do with them. Maybe they save them, maybe they authorize with them, put them on file, come back, use them time, and time, and time again. So the world will be more secure. The overall card system will be more secure, without a lot of heavy lifting by the … Without any lifting at all by online merchants.

Yvette Bohanan:

So with Chrome, or Safari, or whatever is storing and provisioning tokens, right?

Russ Jones:

Yeah.

Yvette Bohanan:

Is the token bound to my device again? Or is it bound to my Chrome instance?

Russ Jones:

It’s hard to tell. The technical details aren’t out. This has been something that Visa has been, through bulletins, has been alerting issuers and acquirers to get ready for this, alerting merchants to get ready for this. Google has been talking about an initial implementation with Visa. But none of it is, this use case is not live in the market as of June of 2022.

Yvette Bohanan:

So EMVCo tokenization, one way or another, is going figure this out. Back to George’s question about the uptake here. It’s like you’re going to take this tokenization cod liver oil, fill a spoon, sprinkled on top of your salad. But somewhere.

Russ Jones:

If there’s anything about this that you think you don’t like-

Yvette Bohanan:

Too bad.

Russ Jones:

It’s sort of like being against the rain. Be against the rain. You can say, “Boy, I hope it doesn’t rain today,” but when it starts to rain, you can’t.

Yvette Bohanan:

You’re in it.

Russ Jones:

You’re in it. So the world … I shouldn’t say just the world of cards-

Yvette Bohanan:

Yeah, that’s the other thing.

Russ Jones:

This EMVCo tokenization model is now active and deployed in ACH. It’s used by the Clearinghouse and RTP. It’s not card system specific. Card system is the original system that used EMVCo tokenization, sort of the justification for why it was developed.

Yvette Bohanan:

But it’s a spec that can be used for anything, really.

George Peabody:

I appreciate how you both are pointing out that a lot of effort has gone into expanding the usage of this approach, because what are we trying to do? We’re trying to make sure that the data that’s transmitting over the network, as much of it as possible, not 5%, but 95%, if it’s captured somehow, is useless. If it’s captured somehow, it’s useless. Now the spec does a lot for that, but driving out the usage of primary account numbers is really the point.

Russ Jones:

Yeah, it is getting to dynamic security codes.

Yvette Bohanan:

Exactly.

George Peabody:

Exactly. And online.

Russ Jones:

So I don’t think the day is coming, 95% of card transactions are going to be tokenized. But 9% is better than 7%. Slowly over time, there’s so many trillions of dollars of purchase volume that flows through these payment systems, and a small percentage is lost to fraud. But that small percentage is still a big number. So if you could reduce that, everyone’s coming out ahead.

George Peabody:

To your point of that, if that capability is built into the browser for every online transaction …

Yvette Bohanan:

I mean you would have to have someone consent to using the browser in that way. But a lot of people do. I think if they understood this a little bit better as consumers, they might decide the trade off is worth it. Right? A lot of people that don’t like to do that right now, maybe …

Russ Jones:

Oftentimes it’s hard. People kind of fall into a couple different camps, I think, just from a behavior point of view. Some people are a little bit carefree about all this stuff, because they know that they’re going to be protected by Visa, or protected by MasterCard. They’ll never be out anybody if something goes wrong.

Yvette Bohanan:

Zero liability. Yeah.

Russ Jones:

There is zero liability guarantees and all this type of stuff. So a lot of people are like, “Why would I want to do this? Why do I even care about this?” Other people, though, are thinking if the flu is going around, I hope I don’t catch it. Some people stop the conversation right there. Other people would say, “If the flu is going around, I hope I don’t catch it, and I think I’ll wash my hands a lot this week, or over the holidays, I’m going to be a little bit careful around.”

Russ Jones:

So people will go out of their way to be safer in some circumstances. If you’re of that mind, one of the few things you can do in the world of cards to be safer is you can use these wallet technology, because they’re the best way to get to use usage restricted payment credentials that have dynamic security codes, that are very hard to use, other than the intended purpose for what they’re set up to do

George Peabody:

So well, when I used to go to a dinner party or a cocktail party and someone would … I’d tell someone what I did, they would ask me, “What’s the safest transaction?” I would absolutely say all of those there are the way to go. I will bring out evil skeptical George here and say that particular message is not one that the card system has been anxious to tell and say, “Oh, we have a more secure way for you to use our systems.”

Yvette Bohanan:

More secure than what? More secure than what I’ve been using for the last 30 years? Wait,

Russ Jones:

More secure than secure.

George Peabody:

Exactly.

Russ Jones:

What we already have is secure. This is more secure.

George Peabody:

I don’t envy any marketing messaging person to have to carry that one forward. That’s a tough message.

Russ Jones:

You’re absolutely right, though. You’re absolutely right, George. That is the big challenge. The traditional thing in marketing is you have these tiers that is good, better, and best. In security, you only have three variations, best, best, and best.

Yvette Bohanan:

Yeah.

George Peabody:

Exactly right. Well, this has been fascinating and really useful, and I hope that, well, for all of our listeners, that you too, when you’re at a cocktail party or hanging out with friends and someone asked you, “What’s the most secure way to pay?” Listen to Russ Jones, use Apple.

Russ Jones:

George, if I could do a shameless plug …

George Peabody:

Oh, by all means.

Russ Jones:

This is the type of stuff we talk about all the time in our payments boot camps. If you really want to understand how payment systems work, you should attend one of these workshops.

George Peabody:

Great. Well, then Yvette, thank you, Russ, as always, thank you. Great to be back with you. Thank you for listening. If you’ve got ideas about who we should have on the show, topics that are important to you, drop us a note at paymentsonfire@glenbrook.com. We’ll love to get your input as we go forward. Yvette, again, thank you very much. Until the next time. Oh, I want to put a shameless plug out for Fanning the Flames podcasts that are out there. Yeah.

Yvette Bohanan:

Our short segments. Yeah, we just recorded a couple. So we’re going to be trying to release those pretty often. Just topical things where we get to talk with other folks at Glenbrook. So I’m doing a couple with Neel Saunshi on some aspects of digital currency systems. What’s an NFT?

George Peabody:

Yeah, no interest at all in digital currency these things days. Right, Yvette?

Yvette Bohanan:

So if people have suggestions for those, drop us a note on paymentsonfire@Glenbrook.com.

Russ Jones:

Yeah, that’s a good way to hang out at the payments water cooler.

George Peabody:

There you go. Love that. Love that.

Yvette Bohanan:

Yeah, well, there’s stuff happening and it’s just payments right now. It’s just continuing to be on fire. I mean, we see this constantly, every day in the news, stuff’s happening. So we’ve got a lot to talk about here. More to talk about than hours in the day. Yeah.

George Peabody:

That’s why we’re here. All right. That’s, of course, why you’re here as well. So thanks again for listening. I hope all is well, do good work, and we all will see you the next time.

Yvette Bohanan:

Take Care.

Russ Jones:

Thank you.