Using Digital Identity Wallets for Payments

Ah, were there already. Okay. Yeah. So this idea of using digital identity wallets for payments is a question. I think a lot of people in the digital identity space and the wallet space are asking. So I thought, I think about it. I work for Consult Hyperion. We are a boutique firm. We are experts in payments and identity. So we have kind of have a, have a foot in both camps. So that's what I'm gonna be talking about. So the first question is, or the first thing to say is you can already use wallets.

Oh, there's a couple of little, little niggles with my, with my deck. 'cause I had a slight problem with my laptop. So this is a, an older version. But anyway, so you can already use digital identity, identity wallets for payments. This is a bit of a cheat.

I mean, this is a wallet that, that you can use for payments Apple pay, and you can also use it for some identity stuff in the US if you're in one of those states where you have a have a mobile driver, mobile driving license, it's not a fully joined up experience. You've got the two separate things, but in the one wallet. So what's the goal? The idea here is that we want something that's a really simple user experience for the customer and we want something that's simple to integrate with. So you can imagine that might be as simple as what I've got here.

You've got the two parties, the payer and the payee. The payee says to the payer, you know, here's, here's what I want you to do. Here's the request to pay, or maybe some data associated with that as well. And then in response, the payer can then just present the payment, payment, some kind of verifiable payment, which could include data as well. This is sort of the vision. We are quite a long way from that.

What I'm gonna do today, my assumption is that this audience is mainly an identity audience, is we're gonna step through four payment scenarios and to ask the question, where does the wallet fit into this payment scenario? And as you'll see with the four examples that I've shown, the answer to that question isn't always straightforward. I thought first we should set some basics though. Bit of payments 1 0 1. So in any payment, there are four main actors. You've got the payer and the payee. The two people that are trying to transact each of those has a banking relationship.

So the payer has a bank and the payee has a bank and that's where their money sits. And so in payments, in the payments world, sometimes we talk about a four party model. Those are the four parties. There are variations on this. You can get a three party model. I'm not gonna go into that detail. I could spend like days talking about this topic, but I won't.

And then, and then, and then usually you have this other entity, the scheme in the middle that joins things together. There are basically two types of payments.

Two, two types of payments. The first one's what you might call a call a pull payment. So in a pull payment, this is what card payments are. The payer is providing information about their payment account to the payee. And then the pay payee goes via their bank. So via the payees bank across the network. And then they pull the payment down to themselves. So the payments from, from the payee against the pay the payers bank. The payers, not really, but they're involved in the sense that they're giving some payment information, but they're not involved directly with their, with their bank.

The other type is what you might call a push payment. So it works the other way around. So in this case, the payee is saying to the payer, this is who I am. So the merchants may be giving a, a merchant ID or something, and then the payer goes to their bank and says, send money to that person. So if you are logging onto your bank and you're typing in someone's IBAN to send them some money, that's a push payment. And you can see there's account to account payments.

Ideal sy, these just examples, the ideal system in the Netherlands, separate credit in faster payments in the uk. Those are all kind of push payment systems. I think you can also think of digital currency. So if you're sending someone a Bitcoin transaction, that's a, that's, that's like a push payment as well.

You know, the address of the place where the money's going and you are, you're sending the money to them. So, oh, and the other thing to say, which I won't really talk about, but it's quite an important issue, is the money, the actual transfer of money can happen real time or in many cases it's delayed. It happens sometime later. That's quite important from a payments point of view because it affects things like liquidity. So we may touch on that later. We'll see. Right. So let's start with the first scenario.

So the, the, the sort of first basic scenario to talk about is point of sale card payments. That's the thing that we're all familiar with. 'cause we've all been doing it for, for ages. So you'll see I've changed some of the terms here.

So the, the payer is referred to as the card holder. So they have a card. Obviously you are paying a merchant. So the merchant has a system, the merchant's bank is called an acquirer, and the cards bank is called an issuer. I'm not gonna do the go through the entire flow, but pick out a couple of, couple, couple of important things. So when you tap your card on a terminal in a shop, what's happening is there's a negotiation between those two bits of technical, those, those two devices.

And what they're doing is basically negotiating on the security controls that are gonna be in place in that transaction. So they're asking, well, does the, does the transaction need to go online? Do I need to authenticate the customer? Those sorts of things. The result of that is that a cryptogram, which we might refer, we might refer to as a credential. I mean it's not a verifiable credential, but it's, it's that kind of thing gets sent from the card generated from the card is given to the merchant in most cases that will be sent online. So via the acquirer over the scheme to the issue.

And the issue will check that that cryptogram is correct, and then they'll send an authorization response message back to the merchant. So the merchant knows whether the payments have been successful or not. There are some offline scenarios as well, but we don't have time to go into that. So the question here is, in this, in this, oh, and I should say as well, that standard is a thing called E-M-V-E-M-V standards are very important in payments, in in card payments. Where would a wallet sit here?

Well, it's obvious because we already know where the wallet sits. It sits there. So if you have an an, an Apple pay or a Google Pay wallet, you load a virtual version of your card onto the wallet and it's interacting with the terminal in exactly the same way that your plastic card does.

I mean, your plastic card is in effect a, a wallet, but it's, it's just more a more constrained device. The, the, the application that gets loaded onto your plastic smart card and the application that gets loaded into the secure element, they're identical. They're exactly the same.

Exactly, exactly the same pieces of software. That wallet can come from two places. So it could be what we might call a scheme wallet or a an OEM wallet.

So the, the wallets Apple or Google or Samsung. And then they have a relationship with the scheme and the provisioning of that wallet is from the issuer via the scheme or the issuer may be able to issue the wallet directly. We've had some regulatory changes in Europe just in the last few weeks, which mean that it's now possible for issuers in Europe to issue wallets onto Apple Pay that behave just like Apple Pay wallets. But you don't have to pay, you know, your fees back to back to Apple. So curve an ounce last week that they're going to do exactly that.

So that this is the straightforward example. So let's move on to something a little bit more involved. E-com e-commerce. So e-commerce card payments. How does that work? So when you do an e-commerce transaction, usually what's happening, I mean in the simple case, you are just filling in a form, typing in your card number, the pan, and maybe some other information like the expiry date and your postcode or whatever else is asked for. There's no security around that at all. You're just providing information.

And so how does the merchant prevent, or how do you prevent the situation where that, that data's phished and then is then used to, you know, conduct a fraud in transaction? Well, this is why we have strong customer authentication that we were just hearing about in from PC two. So in the card payments world, the way this works is there's a, another standard from EMV called three ds, 3D secure, and it invokes an authentication process.

So in effect, what happens is you get redirected from the merchant over to your issuer, and then the customer has to authenticate to the issuer and then there's a response come back. It's actually very similar to the open ID connect flow, except instead of an access token coming back, you're just getting a yes no response. Has this person passed, passed that authentication process that gets you your, your SCA and then that information together, the card information is sent over the, over the network to, to get the payment authorized. So where would the wallet sit in this scenario?

Well, actually it sits here and the reason it sits there is, as you are, as you'll probably know from your experience, you type in the card number with a, with a merchant the first time when you shop at that merchant a second time, you don't have to type again because they're, they're storing that card, a thing we call card on file. So in effect, the merchant's becoming a bit like a wallet. They're storing your card data and then enabling to use that, use that a second time.

In order to do that, they have to satisfy some, some, some rules from the payment card industry called PCI rules because that card data, if it's breached, can then be used, you know, to to to to, to do payments, conduct payments in other, on other sites. So actually they don't install the actual card data. They store an alias of the card and then there'll be some kind of tokenization service maybe provided by the scheme could be independent of the, of, of the card network that's just doing that aliasing process.

I should just add here that there are, that when you do an Apple Pay transaction, it's actually more like the point of sale transaction. But that's, if you wanna ask me about that, I can talk about it later, but we don't have time.

But yeah, so basically the wallet sits there, could a third party provide the wallet? In other words kind of sit in front of the merchant so that you had a wallet that was able to support multiple merchants, which is kind of what you'd want to do with a, with a wallet. Otherwise you have like a wallet per per merchant or per relying party, which kind of doesn't make, it doesn't make sense from an identity point of view.

Well, the answer is yeah, maybe, and there are examples of this. So PayPal, for example, would be, would be this kind of wallet, but they, they then need to satisfy PCI rules themselves. They need to do all the authentication that's necessary.

They, they, and they, they, they, they, they become regulated as well. So yes, it can happen, but there are implications of doing that.

Fourth, third example, sorry. So this is, let's think just about a basic push payment. So I'm sending money from myself to my son, his pocket money or something. Then actually he doesn't, well he actually probably would do a request to pay, but so, so my son does a request to pay and then, then I just log onto my mobile banking and I sent push the money to him. So that's not very interesting. There actually are schemes like the Venmo scheme, which is a peer to peer payment in the states where they kind of insert themselves as an app into the flow.

And then what they're doing is signaling to the banks each end to enable those, those payments to occur for that basic account to account flow. The banking app is probably the closest thing to a wallet, but it's not really a wallet. It's not kind of performing that independent function like a wallet for the peer-to-peer scheme, like a Venmo. Then maybe you could think of the Venmo app as being a little bit more like a wallet, but it doesn't fit very well. And then the, the last scenario I wanted to talk about was open banking. So with open banking you have this first.

So we were hearing about aisp and psps just now as a payer, I'm gonna consent to, to my bank to allow them to give an access token to the payee, the merchant, for example. And then that merchant themselves can instruct the payment on my behalf.

Now, so this is kind of like, it's a push payment, but they're kind of like invoking, it's being invoked the other end. So it's sort of somewhere between a push and a pull payment. What's the thing that's most like a wallet here?

Well, it's the merchant again, the payee. And we have examples also of organizations trying to act like the payee, like, like a wallet here as well. It's not the merchants themselves, but it's those aggregators that are emerging in the open banking space. Organizations like True Layer who will provide, they'll, they'll do this.

So the, the actual merchant is kind of off to the right here and is just talking into that organization. So you can see four different scenarios, four quite different ways that it works and, and, and, and and, and sort of lack of, lack of consistency. So what does this all mean?

Well, I think what it means is the verifi presentation flow that we are talking about in E-I-D-A-S in, in the whole kind of identity wallet space doesn't fit that neatly with current payment flows. I'm doing a talk on Friday where I'm gonna be talking about the digital euro and I think there's an opportunity there to get much more alignment than we have with existing payment flows. But of course, you know, the, the, the payment flows you have today are there already. So you have to kind of work out how to work with them.

I mean, there's no way that you're gonna get terminal manufacturers to support verifiable credentials at point of sale. For example, they're going to carry on using EMV for the foreseeable. And that's so, so you have to work with those things for an identity wallet to become a payment wallet.

Then it's, it's gonna fall into scope of some scheme, rule scheme rules, or it's gonna become, potentially become regulated as some kind of payment institution. So that's an important issue to think about.

And then, then I think it's still quite unclear about who's best place to do that. As you'll see from the previous slides, sometimes the issuers in a place where they can do that. Sometimes it's some entity in the middle, sometimes it's more on the merchant side. So as we think about identity wallets and then how we can combine those with payments, there's, I'm kind of raising questions rather than giving answers, but there's a lot to think about. Thank you very much, Steve. Thank you. We have time for one quick question if there is one. No. Okay. Thank you a lot Steve. Thanks. Cheers. Great.

Good.