Videos & Webinars
The session also covers practical ways to reduce false declines, improve approval rates, and deliver lower-friction digital payment experiences. If you’re focused on strengthening card-not-present (CNP) fraud controls while protecting customer experience, this recording offers a useful view of where secure commerce is headed.
Highlights
Want to dive deeper? Download the companion white paper for a closer look at the convergence of tokenization and 3-D Secure.
{ "@context": "https://schema.org", "@type": "VideoObject", "@id": "https://www.entersekt.com/resources/mastering-the-interplay-of-tokenization#video", "name": "Mastering the Interplay of Tokenization and 3-D Secure", "description": "...", "thumbnailUrl": "ACTUAL-THUMBNAIL-URL", "uploadDate": "2026-03-30", "embedUrl": "https://www.entersekt.com/resources/mastering-the-interplay-of-tokenization", "inLanguage": "en", "isFamilyFriendly": true, "transcript": " Hello, everyone. Thank you for joining us today. Um, exciting conversation ahead, I think, about tokenization and 3DS. Uh, an interesting one, a forward-looking one. for sure. And for those on the other side, again, kind of a carry on from, from what we had, uh, sent out in, uh, a white paper that Glenbrook and Intersect recently did on this topic. Just to level set on what we're getting into today. So again, I think, just for, for everybody who is 00:00:30.900 --> 00:00:35.990 attending, uh, we wanna get into kinda three kinda core topics, and then we'll finish with that Q&A. The first 00:00:36.020 --> 00:00:39.200 topic, we really wanna talk about the convergence of tokenization 00:00:39.220 --> 00:00:41.960 and 3DS. We'll unpack that a little bit, what that 00:00:42.000 --> 00:00:45.040 looks like, um, how we're starting to see some of those silos 00:00:45.060 --> 00:00:50.400 break down. I think it's kind of the second big group, and, and again, we'll, we'll unpack this a lot 00:00:50.580 --> 00:00:51.980 more, is that... Hey, Chris, 00:00:52.140 --> 00:00:57.780 welcome back. Uh, shifting data foundations and the impact to RBA and authentication, so we'll get into that. And then 00:00:57.820 --> 00:01:02.160 topic three we'll get into is kind of the impact on authorization and kind of that customer experience. 00:01:02.220 --> 00:01:06.900 So Chris, welcome. DeWaal, appreciate you both being here. Always good to catch up and talk with you 00:01:07.000 --> 00:01:10.000 two. Uh, do you wanna do quick intros and then, and then we'll kinda 00:01:10.040 --> 00:01:14.080 jump into it? Sure. Sure, yeah. Chris, you wanna 00:01:14.520 --> 00:01:18.020 start with- Yeah, sure. Well, hi, everybody. I'm Chris Riardi. I'm a partner at Glenbrook 00:01:18.060 --> 00:01:24.800 Partners. Uh, we're a payment strategy consulting firm, uh, that's been doing this for about twenty-five years or so. 00:01:24.800 --> 00:01:29.100 Uh, I focus, uh, really working throughout the full payments value chain, working closely 00:01:29.120 --> 00:01:32.220 with merchants, with banks, uh, with service 00:01:32.300 --> 00:01:35.940 providers, uh, with a lot of my focus on fraud and 00:01:36.020 --> 00:01:39.100 risk management. DeWaal, I'll send it over to you. Great. 00:01:39.420 --> 00:01:40.020 Yeah, thanks. 00:01:40.680 --> 00:01:42.100 Hey, everyone, uh, name's 00:01:42.140 --> 00:01:42.940 DeWaal Naude, 00:01:43.340 --> 00:01:46.060 uh, co-founder and chief, and chief strategy officer for 00:01:46.120 --> 00:01:52.220 Intersect. Uh, we're a business that focuses on payment authentication and then securing transactions 00:01:52.260 --> 00:01:58.900 in flight. And, uh, started the business pretty much from, twenty-- in, twenty ten in South Africa. 00:01:59.040 --> 00:02:01.920 Um, and, uh, we've expanded over the years into 00:02:02.020 --> 00:02:08.300 Europe and to the US, and today. we're a global business. And so, uh, have a pretty good idea 00:02:08.360 --> 00:02:10.080 across both merchants 00:02:10.090 --> 00:02:16.760 and issuers, uh, when it comes to transactions. So a, a, a good view of the total, uh, transaction flow 00:02:16.800 --> 00:02:19.040 there. Looking forward to the conversation today. 00:02:19.720 --> 00:02:21.060 Thanks, DeWaal. Thanks, Chris. Appreciate you both. 00:02:21.720 --> 00:02:27.980 Um, okay, jumping in. So kinda alluded to this before, but really want to unpack this, this concept 00:02:28.000 --> 00:02:32.700 and this topic of the convergence of tokenization and 3DS, right? I think we see and hear it more and 00:02:32.740 --> 00:02:34.320 more, and it's, it's pretty rapidly 00:02:34.380 --> 00:02:41.080 accelerating. Um, and they're really no longer independent silos, right? As they start to come together, we're starting 00:02:41.120 --> 00:02:47.060 to see a little bit more of a unified layer across some of the data integrity and the risk management 00:02:47.100 --> 00:02:50.940 and how that's starting to look and how we're approaching that. And so as we kinda think 00:02:51.000 --> 00:02:54.780 about this and see that, Chris, I wanna start with you and just kinda get some of your thoughts of, 00:02:54.840 --> 00:02:55.960 of this convergence and what 00:02:56.000 --> 00:03:01.540 you're seeing and hearing. Yeah. So, so let me first say, first of all, thank you for, having me. Let 00:03:01.560 --> 00:03:06.890 me first say that, you know, this is a topic that not a lot of people are talking about right 00:03:06.920 --> 00:03:13.870 now. It's, it's kind of niche, but at the same time, it is something that is really, really go-- impacting 00:03:13.900 --> 00:03:18.180 today, um, merchants and issuers. And 00:03:18.800 --> 00:03:23.150 i-it-- we will see this have a bigger impact on merchants and issuers in the future, all these 00:03:23.200 --> 00:03:28.440 themes that we're talking about. So, so I think it's really important that we get ahead of this. Uh, I 00:03:28.460 --> 00:03:33.560 think maybe a good way to start is to just talk a little bit about kinda the, the state of 00:03:33.660 --> 00:03:36.080 tokenization and where we stand here. 00:03:36.680 --> 00:03:43.120 Uh, if you look at the messaging that's coming from Mastercard and Visa, tokenization is really, really 00:03:43.140 --> 00:03:48.640 important to their strategy. You just have to listen to their quarterly earnings calls, and out of all the issues 00:03:48.720 --> 00:03:50.040 that Mastercard and Visa deal 00:03:50.080 --> 00:03:57.620 with, they take five minutes out of almost every earning call just to talk about tokenization, V-Visa especially these days. 00:03:57.680 --> 00:03:58.060 That shows 00:03:58.100 --> 00:04:05.760 how important it is. And the messaging that we're hearing from them is incredible growth continues from tokenization, 00:04:06.300 --> 00:04:11.260 almost now at the point that it's, it's almost fifty to a hundred percent year over year in regard 00:04:11.300 --> 00:04:15.190 to network tokens that, that, that are issued through, through both networks. 00:04:15.720 --> 00:04:18.480 Um, so they very much see a future 00:04:18.519 --> 00:04:23.409 where the, the future on their network is comprised of tokenization everywhere, 00:04:23.920 --> 00:04:26.000 either card on file tokens that are kept 00:04:26.060 --> 00:04:26.750 at, at, um, 00:04:27.080 --> 00:04:31.080 at a merchant, um, tokens that are kept in a wallet like an Apple Pay or Google 00:04:31.160 --> 00:04:35.960 Pay wallet, or tokens that might be authenticated at the time of transaction, like, 00:04:36.060 --> 00:04:38.000 like click to pay. Um, and 00:04:38.080 --> 00:04:44.460 I think all of this kind of leads us to, uh, this continued use of tokenization very often leads to 00:04:44.500 --> 00:04:48.050 this misbelief that, um, tokenization 00:04:48.440 --> 00:04:51.600 in all cases equals full credential security, 00:04:52.120 --> 00:04:55.000 and tokenization always equates to identity 00:04:55.080 --> 00:05:00.500 security. And that's not always the case, um, and especially in the case of identity, 00:05:00.800 --> 00:05:00.940 right? 00:05:01.460 --> 00:05:06.960 We do have this concept of authenticated tokens. We have this concept of unauthenticated 00:05:07.060 --> 00:05:15.160 tokens, but the issue is there's weakness in both of those models. Unauthenticated tokens can essentially be requested by anybody. 00:05:15.220 --> 00:05:23.030 Any merchant can, um, request a token. There's no authentication required. And the key thing to note about authenticated tokens 00:05:23.420 --> 00:05:31.680 is that they only address identity validation at the time of provisioning. They don't address identity, integrity, 00:05:32.160 --> 00:05:37.980 or validation through the subsequent life cycle of that token. So I think that's really, really important 00:05:38.020 --> 00:05:43.350 to note. And all of this is gonna be more important in the future as Visa and Mastercard have signaled 00:05:43.400 --> 00:05:44.020 that 00:05:44.060 --> 00:05:51.840 by twenty-thirty, they wanna get rid of, uh, the input of PANs in the clear by consumers. So that by 00:05:51.880 --> 00:06:00.170 default leads us to wallet-driven models, click to pay, card on file tokens, where tokenization is really the foundation 00:06:00.200 --> 00:06:02.120 here. So we really just wanna stress the theme today, 00:06:02.200 --> 00:06:06.100 I think, that tokenization is focused on protecting the credential. 00:06:06.560 --> 00:06:10.000 Three DS Secure is really focused on validating the 00:06:10.040 --> 00:06:15.320 customer, but they have to work together in a layered approach in order to-- for us to get 00:06:15.380 --> 00:06:21.320 sort of a holistic, uh, risk management view, view here. So it's, it's a really complex interplay 00:06:21.380 --> 00:06:23.012 for sure. Yeah. 00:06:23.312 --> 00:06:27.082 Thanks, Chris. And I think, uh, such a good point too on just like the acceleration 00:06:27.112 --> 00:06:32.372 of it and how focused everybody is. And it's interesting the point you made there is we're seeing more on 00:06:32.432 --> 00:06:37.082 the, the consumer and the experience side of those rises in the wallets and the click to pay, right? It's 00:06:37.152 --> 00:06:41.792 almost like we're, we're being forced on the front end to, to, to kinda get there and keep up with 00:06:41.812 --> 00:06:43.202 this. So- Yeah, absolutely. 00:06:43.202 --> 00:06:48.032 Appreciate that. So DeWaal, I think just kinda shifting over here to, I'm interested to get your thoughts. I 00:06:48.072 --> 00:06:50.032 know sometimes when you and I have talked about this in the 00:06:50.072 --> 00:06:50.632 past, uh, 00:06:52.112 --> 00:06:57.192 you, you kindly and wonderfully have both kind of that strategic but also tactical standpoint to, to things. 00:06:57.392 --> 00:06:59.992 Um, so when we think about this maybe from a little bit more tactical 00:07:00.032 --> 00:07:00.912 level, um, 00:07:01.212 --> 00:07:04.132 what are, what are your thoughts here? Sure. And, and I think, 00:07:04.272 --> 00:07:04.832 uh, the, 00:07:05.332 --> 00:07:09.172 you know, just, just to kind of reiterate that, that very important point that Chris 00:07:09.192 --> 00:07:09.752 made, that, 00:07:10.492 --> 00:07:13.532 uh, you know, the, the tokenization, 00:07:14.032 --> 00:07:14.181 uh, 00:07:14.652 --> 00:07:19.392 kind of, you know, the, the, the protocol, the action around it, it's all about kind of securing the credential, 00:07:19.452 --> 00:07:20.552 right? You, 00:07:20.672 --> 00:07:21.932 uh, when you, when 00:07:22.012 --> 00:07:24.212 you have a s-- a, a, let's say 00:07:24.312 --> 00:07:24.392 a, 00:07:24.792 --> 00:07:30.012 a card, right, and you've got-- you can have multiple tokens that are actually tied to that card, right? So 00:07:30.552 --> 00:07:34.022 I know sometimes the, uh, uh, you know, the issuers or the networks will, will 00:07:34.072 --> 00:07:34.302 kind of, 00:07:35.012 --> 00:07:38.212 um, let's say, uh, refer to that, that master, 00:07:38.572 --> 00:07:42.072 you know, card or PAN where all these tokens kinda hang from as the FPAN, 00:07:42.132 --> 00:07:45.112 right, or the, which is that master kind of account. 00:07:45.602 --> 00:07:46.092 And you can 00:07:46.152 --> 00:07:46.812 then kind of, 00:07:47.532 --> 00:07:53.112 you know, issue num-- a, a number of different tokens against it, whether it be one-time use tokens 00:07:53.252 --> 00:07:55.032 or, you know, maybe tokens that 00:07:55.092 --> 00:07:55.952 are specifically, 00:07:56.532 --> 00:08:00.052 uh, let's say, scoped for a specific merchant, specific 00:08:00.112 --> 00:08:00.492 amount. 00:08:01.052 --> 00:08:04.172 That, that really kinda helps you to kind of secure the credential 00:08:04.212 --> 00:08:07.012 and, and, and, and kind of limit the scope of the credential, 00:08:07.072 --> 00:08:08.212 which is a, a great, 00:08:08.892 --> 00:08:11.212 uh, advantage, right, in, in terms of, 00:08:11.772 --> 00:08:11.992 um, 00:08:12.112 --> 00:08:15.332 you know, uh, securing that credential. But as Chris mentioned, 00:08:16.912 --> 00:08:24.232 the ongoing authentication and, and, and making sure that those tokens are used in the intended way by the intended 00:08:24.332 --> 00:08:24.672 person, 00:08:25.132 --> 00:08:26.132 um, or the intended, 00:08:26.252 --> 00:08:33.312 you know, IoT device or agent, right, even, um, that's the part where, uh, sometimes there's 00:08:33.371 --> 00:08:35.102 a, a, I guess 00:08:35.152 --> 00:08:38.912 a little bit of a, a, a lack of, of, of realizing 00:08:39.052 --> 00:08:41.332 that the token in and of itself 00:08:41.652 --> 00:08:46.072 doesn't mean you're now, you know, completely secure. You still have to do that identification. 00:08:46.152 --> 00:08:47.222 You still have to make sure 00:08:47.712 --> 00:08:55.472 on an ongoing continuous basis that the transaction that is performed by that token is in fact, you know, legitimate 00:08:55.572 --> 00:08:56.152 and, and, 00:08:56.232 --> 00:08:58.032 uh, you know, uh, performed in 00:08:58.072 --> 00:09:02.942 a, in a, in a way that's consistent with the mandate or the intent of the 00:09:03.012 --> 00:09:08.972 cardholder, right? And so I think one of the points that I perhaps wanna highlight 00:09:09.032 --> 00:09:09.912 around that is 00:09:11.052 --> 00:09:15.401 there's a almost a little bit of a temptation as you, as you start to kinda think about this tokenized 00:09:15.452 --> 00:09:17.112 world where, uh, you know, 00:09:17.812 --> 00:09:20.172 there's many times, uh, this perception 00:09:20.312 --> 00:09:22.052 that, okay, 00:09:22.252 --> 00:09:25.012 so if we're gonna have these secure credentials, we 00:09:25.092 --> 00:09:26.872 only have to, uh, you know, 00:09:27.092 --> 00:09:29.152 uh, secure the, the issuing of, 00:09:29.532 --> 00:09:33.012 of the, the token. If you issued the token securely after that everything's fine. 00:09:33.432 --> 00:09:35.092 You don't have to continuously authenticate. 00:09:35.521 --> 00:09:36.052 And so what then 00:09:36.112 --> 00:09:37.992 happens is, most of the 00:09:38.052 --> 00:09:40.152 times, uh, if you look at 00:09:40.612 --> 00:09:42.032 just, just some of the discussions that I've 00:09:42.092 --> 00:09:44.162 had, the initial, 00:09:44.492 --> 00:09:52.812 uh, approach to something like tokenization is that we should only do something like strong customer or strong cardholder authentication 00:09:52.852 --> 00:09:58.241 at the point of issuing a token into a wallet or something like that, and not then actually do ongoing 00:09:58.241 --> 00:09:58.982 authentication. 00:09:59.792 --> 00:10:05.122 And what happens essentially in that case, we've seen a couple of studies kind of, uh, around just what happens 00:10:05.152 --> 00:10:13.112 in that case, because what essentially happens when you do that is you're only sending high-risk transactions kind of via 00:10:13.172 --> 00:10:16.092 this rail, uh, you know, for authentication, which 00:10:16.152 --> 00:10:24.021 means the models on the issuer side only sees high risk or bad transactions. And so it never really 00:10:24.052 --> 00:10:25.181 gets to see what 00:10:25.192 --> 00:10:27.032 good looks like. And the, 00:10:27.172 --> 00:10:29.032 the, uh, the challenge with that 00:10:29.112 --> 00:10:31.332 is, um, that it almost becomes 00:10:31.412 --> 00:10:33.032 like, uh, you know, this, 00:10:33.192 --> 00:10:37.072 this, uh, let's say scenario of, of, of, of kind of trying 00:10:37.112 --> 00:10:41.072 to, to get insurance for something that happened already, right? Uh, in the 00:10:41.132 --> 00:10:41.692 sense that, 00:10:42.272 --> 00:10:47.942 uh, you, you, you can't go back, uh, once, once something's happened and then say, "Oh, oh, yeah, now, 00:10:48.092 --> 00:10:49.032 now I want protection 00:10:49.092 --> 00:10:49.972 for it." There's kind 00:10:50.012 --> 00:10:54.972 of like a, a learning period, right, that's kinda required to see, oh, this is what good looks like over 00:10:55.092 --> 00:10:57.992 time, you know, in the same way that you would have to have a policy for 00:10:58.012 --> 00:10:59.272 some time before it will actually, 00:10:59.632 --> 00:11:00.232 you know, protect 00:11:00.252 --> 00:11:00.982 you, uh, from 00:11:01.032 --> 00:11:03.072 an insurance perspective. And so I think, uh, 00:11:03.592 --> 00:11:08.072 that's something that, that perhaps, uh, when we think about this and when we start to design 00:11:08.092 --> 00:11:09.152 for this tokenized world, 00:11:09.792 --> 00:11:13.092 uh, that we-- that I, I think it's gonna be very important to, to kinda keep 00:11:13.112 --> 00:11:13.951 in the back of your mind is 00:11:14.012 --> 00:11:15.992 that there is, uh, 00:11:16.192 --> 00:11:18.332 you know, a, a requirement still 00:11:18.992 --> 00:11:21.952 to secure the transaction and to, and to on an ongoing 00:11:22.072 --> 00:11:25.232 basis actually use the tools for data sharing, 00:11:25.752 --> 00:11:29.152 uh, between a merchant and an issuer to be able to train the models in the correct 00:11:29.212 --> 00:11:31.072 way so that when the bad transactions do 00:11:31.112 --> 00:11:36.152 come, those models are equipped to make the right decision. Um, and, and so that's something 00:11:36.192 --> 00:11:39.452 that, that I think is gonna be very important from a tactical perspective, 00:11:39.992 --> 00:11:44.152 uh, when it comes to how we actually, you know, deploy these things. And of course, three secure 00:11:44.572 --> 00:11:46.332 when it comes to e-commerce is a very powerful 00:11:46.412 --> 00:11:47.912 tool, uh, and an existing 00:11:48.012 --> 00:11:52.092 tool to do that, to actually share that data, you know, from merchant to 00:11:52.212 --> 00:11:57.052 issuer, uh, and to enable them to actually then, you know, build the models and properly secure 00:11:57.092 --> 00:12:03.472 those transactions on a continuum base-- continuous basis. Thank, thanks so much. I appreciate the, uh, you know, you can't 00:12:03.492 --> 00:12:07.572 go back. Um, but I wanna use, I wanna use that too, right, in terms of like the concept of 00:12:07.592 --> 00:12:09.212 the use cases and how we're getting into 00:12:09.252 --> 00:12:12.032 it 'cause again, starting to look at kind of 00:12:12.092 --> 00:12:14.552 the, the next, you know, part of the conversation, 00:12:14.912 --> 00:12:21.112 we're seeing those shi- shifting kinda data foundations and really the impact across RBA and how it's, it's 00:12:21.172 --> 00:12:27.368 starting to change visibility and the quality of the data available. And so-With that, you know, again, 00:12:27.857 --> 00:12:32.418 y-to your point, like, there feels like there's almost a little bit of a, you know, maybe recalibration 00:12:32.448 --> 00:12:37.068 or like how do we look at some of the models that we currently have employed. Um, and so, 00:12:37.088 --> 00:12:42.968 Dull, I kinda wanna start with you there. As like we think about this foundational shift in, in RBA, 00:12:43.008 --> 00:12:44.978 what are the key things that kinda stand out for 00:12:45.008 --> 00:12:47.948 you? Yeah. I, I think it's, 00:12:48.088 --> 00:12:53.068 it's, um, w-we're, we're, we're blessed at the moment with, um, 00:12:53.908 --> 00:12:58.008 a lot of data, the ability to share a lot of data in, in, in real time, right? 00:12:58.188 --> 00:12:59.148 Um, if you look at, 00:12:59.888 --> 00:13:04.188 at, uh, you know, some of the protocols, uh, something like Three Secure as an example, has 00:13:05.108 --> 00:13:12.088 150 data elements, right? That it actually sends across. And, um, I think if you really look at 00:13:12.148 --> 00:13:17.258 evaluating and the richness of that data that actually a-allows you to make a good decision around 00:13:17.308 --> 00:13:17.538 that, 00:13:18.228 --> 00:13:24.568 um, we s- we, we start to, to get into a world where we probably need to kind of, you 00:13:24.608 --> 00:13:30.998 know, get rid of the hangover Three Secure one in the sense that Three Secure one was, was 00:13:31.068 --> 00:13:35.278 very much like a, a way for you to kind of challenge a cardholder, right? So it was kind of 00:13:35.308 --> 00:13:40.908 almost like a, let's say like a, a, a security checkbox, so to speak, right? Like, hey, 00:13:41.068 --> 00:13:43.168 you know, like if, if there's risk, 00:13:43.308 --> 00:13:48.068 you know, let's, let's, let's use Three Secure so that we can actually challenge someone. So that's why in, 00:13:48.068 --> 00:13:50.028 in, in a lot of cases, because of 00:13:50.088 --> 00:13:55.008 the, the, the limited kind of data sharing elements and capabilities that that protocol 00:13:55.068 --> 00:13:58.288 had, you would see that it was mostly used for challenges. 00:13:58.328 --> 00:13:58.848 And of course, 00:13:59.308 --> 00:14:03.088 when there's a, a challenge always kind of, uh, approached to something like that, 00:14:03.628 --> 00:14:06.988 uh, merchants would try to kind of avoid that a little bit just to make sure that, hey, okay, 00:14:07.188 --> 00:14:11.028 you know, only the ones that we want challenged, we would send via this rail. I think what 00:14:11.088 --> 00:14:13.028 we're starting to see now with the, uh, you 00:14:13.068 --> 00:14:19.628 know, the, let's say, the new version of these protocols is that with these rich data elements and with the 00:14:19.688 --> 00:14:23.188 schemes and things like tokenization actually starting to, 00:14:23.228 --> 00:14:25.008 to, uh, provide much 00:14:25.048 --> 00:14:30.278 more high quality data in that message that actually comes through to the issuer, 00:14:31.128 --> 00:14:38.188 that tool that used to be a compliance tick box now becomes something that's actually an authorization, uh, 00:14:38.228 --> 00:14:39.577 you know, optimization 00:14:39.888 --> 00:14:46.268 tool, in the sense that you have a lot of, of data elements that you can actually, 00:14:46.408 --> 00:14:49.268 uh, you know, look at, and you can evaluate that, 00:14:49.888 --> 00:14:53.898 uh, without the time pressures that you typically see on the authorization, uh, stream at that 00:14:54.008 --> 00:14:57.228 stage, because this is authentication that happens prior to authorization. 00:14:58.008 --> 00:15:00.288 And what that means is you... 00:15:00.708 --> 00:15:02.068 With that rich data that you can 00:15:02.108 --> 00:15:07.028 look at, you can frictionlessly approve a lot of that. And so it actually becomes 00:15:07.088 --> 00:15:10.288 a way for, for, um, you know, issuers and merchants 00:15:10.348 --> 00:15:14.188 to, prior to the transaction kinda happening, already kinda getting that green 00:15:14.288 --> 00:15:17.008 light from the issuer that, "Hey, yeah, I'm happy with this. When 00:15:17.048 --> 00:15:19.188 you submit it, everything's gonna be great." 00:15:19.848 --> 00:15:25.088 And we're starting to see some of the, uh, um, you know, some of the organizations that really have, 00:15:25.268 --> 00:15:26.008 have made that 00:15:26.048 --> 00:15:32.428 shift from a compliance tick box kind of approach towards a authorization optimization strategy, 00:15:32.908 --> 00:15:38.068 uh, using this much more to kind of, uh, you know, really kind of mark transactions for good, 00:15:38.748 --> 00:15:42.118 uh, versus just trying to, to, to see the bad ones for authentication. 00:15:42.988 --> 00:15:49.068 Seeing some really good results where your authorization uplift is quite, quite significant and, and measurable, right? 00:15:49.158 --> 00:15:49.548 And so, 00:15:50.168 --> 00:15:53.128 uh, definitely something that I think is gonna be key 00:15:53.608 --> 00:15:54.028 and is a 00:15:54.088 --> 00:15:58.008 key way of thinking about it, uh, going forward because you now 00:15:58.088 --> 00:16:01.108 have the data. Um, and, and I think that kind of also 00:16:01.408 --> 00:16:02.048 becomes more 00:16:02.088 --> 00:16:03.988 important as we go into 00:16:04.028 --> 00:16:07.208 some of these new, you know, trends that are kind of in the, in the industry. 00:16:07.798 --> 00:16:12.248 You know, tokenization and, and, you know, these, these rich data share journeys 00:16:12.908 --> 00:16:17.168 become all the more important as we, uh, as we start to kind of enter into the world of agentic 00:16:17.188 --> 00:16:18.188 commerce, right? Agentic 00:16:18.197 --> 00:16:18.608 commerce, 00:16:19.348 --> 00:16:22.208 uh, you know, something that's obviously very topical at the moment. 00:16:22.988 --> 00:16:23.068 But 00:16:23.128 --> 00:16:28.028 if you look at it, the, the frameworks that are being de- uh, kind of developed by the schemes around 00:16:28.088 --> 00:16:33.028 how agentic commerce will kinda play out is very much rooted in things like tokenization, 00:16:33.528 --> 00:16:40.188 uh, cardholder mandates that, um, you know, are sent with that. And so you're getting things like proof 00:16:40.208 --> 00:16:42.008 from the c- the, the cardholder, proof 00:16:42.068 --> 00:16:47.267 that they've already, uh, authenticated and, and given a mandate to an agent to execute 00:16:47.277 --> 00:16:52.988 within. And that proof is sent together with the agent transaction kind of over these rails, which means 00:16:53.028 --> 00:16:57.228 by the time that something like a ACS on the Three Secure side, an issuer gets that, 00:16:58.148 --> 00:17:01.208 they've got all the data to prove that the cardholder has looked at this, 00:17:01.568 --> 00:17:01.728 cardhold- 00:17:02.028 --> 00:17:03.008 cardholder has approved 00:17:03.048 --> 00:17:06.887 it, um, and you know, this is a registered agent, for example, right? 00:17:07.008 --> 00:17:10.968 There's things like know your agent now registration protocols kind of as part of 00:17:11.028 --> 00:17:13.127 that, that, uh, framework 00:17:13.167 --> 00:17:15.167 as well. And so what that means 00:17:15.268 --> 00:17:15.428 is 00:17:16.228 --> 00:17:21.248 this, this same tool that you kind of used, uh, you know, with your normal, uh, commerce 00:17:21.708 --> 00:17:25.328 now has the ability to kinda look at these additional fields, these additional 00:17:25.367 --> 00:17:31.798 data fields, and frictionlessly approve much more of these transactions. And then by the time that they hit your authorization 00:17:31.928 --> 00:17:37.148 stream, you've already got that green tick box there to say, "Hey, we've already looked at this. We're happy 00:17:37.188 --> 00:17:39.068 with this. Nothing to see 00:17:39.078 --> 00:17:41.998 here. Let's go." And that really then is, is kind of 00:17:42.028 --> 00:17:48.348 the opportunity here, um, you know, to kind of reuse, uh, some of these capabilities, uh, that's, that are already 00:17:48.408 --> 00:17:49.048 implemented in 00:17:49.088 --> 00:17:54.128 a, in a more, you know, let's just say like a more, uh, 00:17:54.128 --> 00:17:57.168 uh, constructive way versus a compliant 00:17:57.228 --> 00:18:03.028 way. Awesome. Thank, thanks a lot. I was wondering too if you're gonna touch on the agentic thing. 00:18:03.168 --> 00:18:07.018 Uh, so I'm glad you did. I feel like we could take a whole separate conversation if everybody- 00:18:07.018 --> 00:18:09.968 Right, right ... wants to come back for the second version of this, this, 00:18:10.048 --> 00:18:14.908 uh, live discussion, we'll, we'll do it on agentic commerce. But, uh, thanks. So Chris, again, 00:18:15.028 --> 00:18:21.208 kinda keeping this topic here with you. I think you obviously, Glen- Glenbrook, super close with, you know, FIs and 00:18:21.268 --> 00:18:26.698 merchants in the market in, in those conversations. And so how are you kinda seeing some of, you know, those, 00:18:26.788 --> 00:18:32.668 those different audiences and segments really lean into like the, the value of this shift? Is, is there- Yeah ... 00:18:32.668 --> 00:18:34.028 some early indicators? How are they kind of 00:18:34.068 --> 00:18:39.658 approaching it? Yeah. So, so I, I maybe want to emphasize or put a finer point on some of the 00:18:39.698 --> 00:18:42.018 points that, um, Dewald raised 00:18:42.058 --> 00:18:47.158 earlier. Um, first thing is I think we have historically had this 00:18:47.218 --> 00:18:52.358 notion of, Dewald used the term of, of three DS secure being a compliance checkbox, 00:18:52.878 --> 00:18:54.018 right? And I think what you mean by 00:18:54.078 --> 00:18:57.018 that, Dewald, is that we know in some major 00:18:57.538 --> 00:19:00.138 geographies like the UK and Europe, for example, 00:19:00.598 --> 00:19:05.018 we have requirements under PSD two and the forthcoming PSD three that says 00:19:05.498 --> 00:19:09.178 you have to do some type of strong customer authentication. 00:19:09.938 --> 00:19:12.978 Very often, three DS secure is the way that that is accomplished, 00:19:13.058 --> 00:19:14.238 right? But 00:19:14.678 --> 00:19:22.128 m- merchants very often are not really putting the effort into kind of the, the, the next step of executing 00:19:22.158 --> 00:19:27.058 a three DS secure authentication, which is ensuring that the data is robust, the data 00:19:27.118 --> 00:19:31.978 is consistent, and the data is good. They're just sort of executing it, you know, 00:19:32.078 --> 00:19:36.998 to, to, to check the box, if you will, from a compliance perspective, and, and that has 00:19:37.078 --> 00:19:38.538 been a problem 00:19:38.998 --> 00:19:39.078 for 00:19:39.138 --> 00:19:45.138 a long time. But this is a little bit of a chicken and egg situation, right? Because you've had this 00:19:45.158 --> 00:19:47.118 historical issue of merchants saying, 00:19:47.618 --> 00:19:53.248 "Well, you know, I don't maybe put a lot of trust in three DS secure decisioning because I'm not getting 00:19:53.258 --> 00:19:56.298 good decisions coming back from issuers." And then issuers 00:19:56.358 --> 00:19:58.238 saying, "Well, I can't 00:19:58.698 --> 00:20:02.058 really come back with quality responses because the data I'm getting 00:20:02.478 --> 00:20:02.918 is pretty 00:20:03.058 --> 00:20:10.298 poor." So, so, you know, that's a historical problem, right, where low quality data leads to sort of low issuer 00:20:10.418 --> 00:20:17.978 confidence, which leads to poor three DS performance or more friction, um, at the consumer level. So I think that's 00:20:18.038 --> 00:20:19.218 a historical problem. 00:20:19.718 --> 00:20:27.278 I think the smart merchants, however, have been taking advantage of the expanded data set capabilities that we've been talking 00:20:27.338 --> 00:20:27.618 about, 00:20:28.258 --> 00:20:31.318 really focusing on enriching the data stream 00:20:31.778 --> 00:20:35.058 and also taking it to the next level and understanding 00:20:35.518 --> 00:20:43.198 which issuers are better at actually using that data, um, than others and, and being adaptive in how they approach 00:20:43.208 --> 00:20:48.338 their, their requests to issuers. So I do know a number of, 00:20:48.438 --> 00:20:56.818 uh, you know, major merchants that put a lot of effort into doing issuer and BIN, even within an issuer, 00:20:56.958 --> 00:21:06.487 BIN-level profiling, um, on those issuers to understand how they adjust their authentication strategy as a result, their tokenization 00:21:06.538 --> 00:21:08.118 and their authentication strategy. 00:21:08.638 --> 00:21:13.707 Um, and we should note that everything that I've just talked about regarding three DS authentication, 00:21:14.018 --> 00:21:17.327 there's kind of a parallel to that with tokenization 00:21:17.358 --> 00:21:21.018 as well. Merchants see various performance profiles 00:21:21.098 --> 00:21:23.278 from issuers. Um, they see various 00:21:23.318 --> 00:21:24.118 perf- uh, 00:21:24.698 --> 00:21:25.078 performance 00:21:25.158 --> 00:21:33.118 profiles on, on sets of bins from issuers. And, uh, the smartest of merchants sometimes will say, 00:21:33.128 --> 00:21:37.118 "I'm not even going to send a token down the line to this issuer. I'm going to revert 00:21:37.198 --> 00:21:41.198 back to PAN." Or they'll say, "I'm going to go with a token to start with, 00:21:41.578 --> 00:21:44.258 and I'm going to fall back to PAN if I get a decline." 00:21:44.638 --> 00:21:48.098 So we have this really, really fragmented environment now, 00:21:48.578 --> 00:21:54.918 both on the three DS end and the tokenization end that's making this very, very challenging, um, 00:21:55.018 --> 00:22:01.058 uh, for merchants. But the bottom line is better data equals better approvals, and we want to get to 00:22:01.118 --> 00:22:04.118 a point, going back to kind of what Dewald was talking 00:22:04.158 --> 00:22:06.978 about earlier, where three DS, the presence 00:22:07.018 --> 00:22:10.038 of three DS is not looked at as a risk 00:22:10.178 --> 00:22:12.178 signal. It's looked at as a trust 00:22:12.298 --> 00:22:17.438 signal, right? And in this scenario where merchants are saying, particularly in unregulated geographies, 00:22:17.898 --> 00:22:21.058 "Hey, I'm only going to send the riskiest of transactions to 00:22:21.098 --> 00:22:24.038 an issuer," that makes three DS 00:22:24.458 --> 00:22:27.038 a, a risk signal and not a trust signal. But if 00:22:27.078 --> 00:22:31.078 a merchant starts building good data sets, consistently sending 00:22:31.118 --> 00:22:34.958 it down the line, using data only rails and such, which we'll talk about in, in 00:22:35.018 --> 00:22:41.568 a second, that starts to, to, to shift the balance from risk to trust and allows the issuers to make 00:22:41.678 --> 00:22:43.068 much better informed decisions on 00:22:43.098 --> 00:22:48.068 the merchant's behalf. Yeah. Thank, thanks, Chris. And on John notes, I think that's such a key thing, the trust 00:22:48.118 --> 00:22:51.978 signal, right, and the better data driving kind of better decisions and, and how we all leverage 00:22:52.018 --> 00:22:57.098 that. I'll, uh, I'll go on record with a quick controversial statement too. Everyone heard it here. I think egg, 00:22:57.218 --> 00:22:59.078 egg came first, right? It was definitely the egg. 00:23:00.058 --> 00:23:00.498 Um, 00:23:00.938 --> 00:23:01.138 okay. 00:23:01.238 --> 00:23:01.498 So, 00:23:03.578 --> 00:23:08.798 uh, thank you both. A- again, I think we're, we're really stressing and covering across the, again, the, the data 00:23:08.978 --> 00:23:12.118 really is only, only as good as the outcome it produces and how we kind of leverage 00:23:12.138 --> 00:23:17.818 that and what the actual impact is across some of these use cases, and particularly when we think about, right, 00:23:17.878 --> 00:23:22.377 like authorization rates and what that looks like. And so kind of, kind of segue into, Chris, what you hit 00:23:22.438 --> 00:23:28.148 on there too is, is we, we look at this, right, and as kind of, you know, 00:23:28.148 --> 00:23:35.378 w- the impact of tokenization three DS on that authorization and that customer experience, um, the balance, the approval, 00:23:35.758 --> 00:23:37.978 you know, all of those things that come into it. How do, how do you 00:23:38.038 --> 00:23:39.018 kinda look 00:23:39.038 --> 00:23:44.098 at that, and what are your thoughts? Yeah. It, it is a balance, and you know, I, I think we 00:23:44.298 --> 00:23:49.338 all agree that false declines are probably the biggest driver of a poor 00:23:49.718 --> 00:23:57.187 user payments experience. There's nothing more frustrating than that because often the path to resolution, um, fr- 00:23:57.187 --> 00:23:58.858 from a, from a customer perspective 00:23:59.038 --> 00:24:01.298 is, uh, it's tough, right? 00:24:01.418 --> 00:24:06.054 Is sometimes they have to fall back to another cr-Payment type or credential. 00:24:06.494 --> 00:24:09.034 Other times they actually get-- have to get to the point where they pick 00:24:09.094 --> 00:24:11.214 up the phone, and they have to speak to a, a bank, 00:24:11.254 --> 00:24:16.334 right? That's a terrible, terrible customer experience that we, we want to avoid. 00:24:16.874 --> 00:24:22.574 Um, we know, however, that tokenization does really help improve the user experience. 00:24:23.054 --> 00:24:29.074 Uh, we have various statistics, uh, around this. Uh, you know, we talked to a number of merchants, merchants that 00:24:29.114 --> 00:24:35.214 have seen sort of, uh, negligible but positive, um, uh, improvements when tokenization 00:24:35.254 --> 00:24:39.394 is present, all the way up to those who are seeing five, six percent uplift, 00:24:39.914 --> 00:24:44.454 um, sometimes even more if it's a subscription and recurring merchant when tokenization 00:24:44.514 --> 00:24:49.694 is used. Um, Visa, MasterCard, their position on this depends on which side of the bed they get up every 00:24:49.754 --> 00:24:50.054 morning-- 00:24:50.254 --> 00:24:53.073 on the morning. The, the story change-- seems to change every 00:24:53.134 --> 00:24:59.394 quarter. But I would say, you know, their line has been somewhere between like three to five percent uplift 00:24:59.474 --> 00:25:00.914 across the network fro-from 00:25:01.014 --> 00:25:09.333 a, a tokenization perspective. So tokenization, a lot of that benefit from tokenization, that authorization uplift benefit 00:25:09.794 --> 00:25:16.304 is, is really coming from the lifecycle management aspect of tokens, where we know that as the underlying 00:25:16.374 --> 00:25:20.174 credential, the underlying PAN, if it changes, if it's been lost 00:25:20.194 --> 00:25:22.084 or stolen, if it expires, 00:25:22.134 --> 00:25:26.484 et cetera, most importantly, the token doesn't change. So just by their very nature, 00:25:27.014 --> 00:25:31.474 um, tokens, the lifecycle management feature of tokens helps enable, 00:25:31.554 --> 00:25:32.474 um, better, 00:25:32.594 --> 00:25:34.204 uh, uh, authorization 00:25:34.274 --> 00:25:38.934 rates, right? But, but, but again, this is very, very credential 00:25:39.014 --> 00:25:46.514 focused, right? Three DS in parallel is, is more identity focused and more focused on the individual, 00:25:46.974 --> 00:25:48.204 right? And we know that, 00:25:48.834 --> 00:25:49.104 as we've 00:25:49.114 --> 00:25:56.634 been saying, is three DS helps improve issuer decisioning, particularly when the data is very good there. So I, I 00:25:56.714 --> 00:26:01.074 think that the message here that we have to, to, um, continue to stress, we're 00:26:01.114 --> 00:26:07.244 talking about consumer experience, is the two of these have to work together in this layered approach. 00:26:07.734 --> 00:26:13.234 You need to make sure that you're using tokenization in the right way to manage your, your, your lifecycle. 00:26:13.254 --> 00:26:17.314 If you're doing that efficiently, effectively, that's going to help your consumers. 00:26:17.774 --> 00:26:20.914 Um, you have to ensure that you've got good three DS data 00:26:21.054 --> 00:26:22.094 pipeline, that 00:26:22.134 --> 00:26:25.354 you're, you know, thinking beyond just, you know, executing 00:26:25.374 --> 00:26:27.174 three DS, using good data, 00:26:27.554 --> 00:26:27.914 doing 00:26:28.334 --> 00:26:31.994 a bit of issuer profiling, BIN profiling, things along those 00:26:32.034 --> 00:26:33.214 lines. And those 00:26:33.714 --> 00:26:37.134 two together are going to lead to higher approval rates and lower 00:26:37.174 --> 00:26:38.194 friction, um, 00:26:38.594 --> 00:26:39.374 for the consumer. 00:26:40.554 --> 00:26:41.063 Awesome. Thanks, 00:26:41.134 --> 00:26:43.994 Chris. Uh, and Dwelle, I want to keep this here, just get your thoughts as well. 00:26:44.054 --> 00:26:47.434 So when we again think about the impact authorization kind of areas for improvement, 00:26:47.654 --> 00:26:47.834 um, 00:26:48.354 --> 00:26:51.014 what's your take? So, so this 00:26:51.094 --> 00:26:56.074 is, this is a, a, you know, a very, very important kind of distinction, Chris, that you, that you highlight 00:26:56.134 --> 00:27:00.074 here, right? In terms of the, the, the credential and the impact of a credential. 00:27:00.174 --> 00:27:04.754 Yes, uh, you know, you mentioned like a three to five percent or six percent in some cases kind of 00:27:04.814 --> 00:27:07.214 uplift, uh, when you look at the credential. 00:27:07.214 --> 00:27:08.054 I'll, I'll, I'll take 00:27:08.794 --> 00:27:09.954 whereas something like 00:27:10.014 --> 00:27:12.204 fully secure provides 00:27:12.674 --> 00:27:17.014 the, the data that actually allows you to, you know, evaluate the, the identity piece, tie 00:27:17.034 --> 00:27:21.314 the identity piece to that credential. And why that's important, let me, 00:27:21.414 --> 00:27:27.674 uh, let me use a practical example, because we, we recently worked with a, you know, with a very frustrated 00:27:27.774 --> 00:27:30.114 merchant, um, in, in one of our territories with 00:27:30.154 --> 00:27:38.014 a, you know, where I think something like, uh, eighty percent of their transactions were being challenged, right? Um, and 00:27:39.074 --> 00:27:39.974 they were getting, uh, 00:27:40.054 --> 00:27:42.074 you know, a, a, a lot of abandonment, 00:27:42.394 --> 00:27:47.094 uh, around that. And so we were kind of looking into, okay, how can we help? 00:27:47.794 --> 00:27:47.954 You know, 00:27:48.014 --> 00:27:51.094 what, what's, what, what can we do to actually im-im-improve the 00:27:51.134 --> 00:27:55.994 situation? And what it came down to was, uh, you know, the, the data that the merchant was sending 00:27:56.034 --> 00:27:57.194 through was actually very, 00:27:57.274 --> 00:27:58.294 very poor. 00:27:58.774 --> 00:28:00.254 And because of that, the issuer 00:28:00.714 --> 00:28:01.234 was making, 00:28:01.314 --> 00:28:03.014 you know, looking at the data and going like, 00:28:03.034 --> 00:28:03.974 "Hey, this doesn't look good, 00:28:04.294 --> 00:28:10.974 let's challenge." And so by working with that merchant to actually capture the right data elements and send it 00:28:11.034 --> 00:28:15.164 over to the issuer, we made that eighty percent of their transactions 00:28:15.194 --> 00:28:21.434 are frictionless, which was a massive uplift on the success of their transactions, right? And so I think that's the 00:28:21.514 --> 00:28:23.284 point is that 00:28:23.313 --> 00:28:25.994 data and good quality data when 00:28:26.014 --> 00:28:26.753 it comes to risk-based 00:28:27.274 --> 00:28:31.034 deci-decisioning and, uh, you know, in terms of authorization, optimization 00:28:31.754 --> 00:28:33.134 plays such a crucial role, 00:28:33.794 --> 00:28:36.194 uh, because it really kind of helps you to, 00:28:36.254 --> 00:28:37.954 to make good decisions 00:28:38.194 --> 00:28:41.114 quickly. If you see all the right 00:28:41.274 --> 00:28:43.174 stuff, that's a very 00:28:43.214 --> 00:28:48.954 quick yes, um, and, and that's what everyone wants. And so I think you mentioned, uh, 00:28:49.174 --> 00:28:55.094 earlier, Chris, that, you know, some of the, the, the smart merchants are, are really kind of investing in, 00:28:55.154 --> 00:28:56.274 in, in data quality 00:28:56.354 --> 00:28:58.354 heavily. And I, I cannot 00:28:58.974 --> 00:29:05.074 kind of agree more in terms of where we've seen the highest like double dig-digit kind of authorization 00:29:05.154 --> 00:29:08.134 uplifts have been where data quality was 00:29:08.174 --> 00:29:10.054 addressed, uh, you know, via these 00:29:10.074 --> 00:29:12.034 rails. And so I certainly think that 00:29:12.094 --> 00:29:14.954 is-- that's kind of where the, the key of 00:29:15.034 --> 00:29:18.044 all, all, all of this kind of, you know, how these two things kind 00:29:18.234 --> 00:29:22.154 of work together, work, uh, uh, uh, quite well. If you think about 00:29:22.634 --> 00:29:24.214 tokenization as a capability, 00:29:25.654 --> 00:29:26.094 why that 00:29:26.134 --> 00:29:34.074 helps, again, you have the ability to make the risk that is around that credential. You can reduce 00:29:34.084 --> 00:29:39.794 the risk around the credential. You can limit the scope of it. "Hey, this token is only, you know, usable 00:29:39.814 --> 00:29:43.034 at this merchant, only up to this amount." So you can actually reduce 00:29:43.054 --> 00:29:50.154 the risk associated with a specific credential. So that in and of itself already helps with the decision that the 00:29:50.214 --> 00:29:52.054 issuer is making. And then at the same time, 00:29:52.434 --> 00:29:55.034 if you layer the identity information, the correct, 00:29:55.094 --> 00:30:00.074 you know, uh, uh, data that says, oh yeah, and, and, uh, if you look at the 00:30:00.094 --> 00:30:05.044 spending patterns and, and you look at the, the behavior of this, of this, uh, consumer 00:30:05.394 --> 00:30:10.930 that's actually initiating this transaction, this is consistent with everything that we've seen.That's put together- Yeah ... then actually 00:30:11.050 --> 00:30:12.210 that's your slam dunk. 00:30:12.810 --> 00:30:16.970 Yeah. And that really, um, then gets you that, that, that, that home run slam 00:30:17.050 --> 00:30:17.970 dunk kind of, uh, you know, 00:30:18.270 --> 00:30:20.970 uh, uh, scenario that, that we're all kind of after 00:30:21.050 --> 00:30:21.570 here. And so 00:30:22.330 --> 00:30:25.970 that would be kind of the thing that, that I think is, is, is really, really 00:30:26.110 --> 00:30:29.030 key here, um, of, of how these two worlds kind of play 00:30:29.070 --> 00:30:29.510 together. 00:30:30.050 --> 00:30:33.190 And then, you know, Chris, you, you kinda mentioned earlier, 00:30:33.850 --> 00:30:33.930 uh, 00:30:34.010 --> 00:30:37.070 you know, initiatives like data-only. And, and I don't know 00:30:37.670 --> 00:30:39.170 whether we wanna quickly talk about 00:30:39.190 --> 00:30:46.170 that, but that certainly is one of the mechanisms that, that kinda helps with that specific, uh, uh, you know, 00:30:46.410 --> 00:30:51.090 area of concern, right, where, uh, data-only kind 00:30:51.130 --> 00:30:53.410 of, uh, is a, is a three secure 00:30:53.930 --> 00:30:57.150 transaction type that enables a merchant to share these data 00:30:57.230 --> 00:30:59.090 elements without 00:30:59.390 --> 00:31:01.870 the risk that the, the issuer is actually going to challenge. 00:31:02.130 --> 00:31:05.090 So- Yeah ... uh, where many merchants were kind of, uh, 00:31:05.810 --> 00:31:06.070 let's 00:31:06.090 --> 00:31:06.320 say, 00:31:06.630 --> 00:31:06.780 uh, 00:31:07.130 --> 00:31:07.810 very, very, 00:31:08.790 --> 00:31:11.150 uh, uh, kind of, uh, uh, let's say 00:31:12.670 --> 00:31:19.140 just nervous about sending something via three secure due to how an issuer might, you know, implement their challenge strategy, 00:31:19.830 --> 00:31:22.210 something like data-only kind of guarantees that the issuer 00:31:22.710 --> 00:31:26.010 will not do that, but still gives you the benefit of actually sharing that data with 00:31:26.030 --> 00:31:32.060 the issuer and then getting the issuer to be able to consider that as part of their authentication and authorization 00:31:32.130 --> 00:31:35.010 strategy. And that I think is the almost that, that 00:31:35.070 --> 00:31:39.050 golden midway that then really kinda can help us to get to a place where 00:31:39.490 --> 00:31:40.970 we move away from this as 00:31:41.010 --> 00:31:45.050 an authentication or strong customer authentication, you know, tick box towards 00:31:45.190 --> 00:31:47.470 more of an au- authorization optimization 00:31:47.590 --> 00:31:49.030 tool, uh, that, that 00:31:49.070 --> 00:31:49.830 this becomes. Agreed. 00:31:50.230 --> 00:31:52.090 Yep, for sure. Yep. 00:31:53.090 --> 00:31:53.170 We 00:31:53.250 --> 00:31:53.790 d- and it's, 00:31:54.230 --> 00:31:58.010 a-and again, it is really amazing and all of us in it, you know, folks on the 00:31:58.030 --> 00:32:03.800 other side live and breathe in it every day, the, the shift to the impact and importance of data in 00:32:03.830 --> 00:32:08.590 this whole ecosystem, right? And, and how we're leveraging and how we're using it is just, it's, it's changing so 00:32:08.610 --> 00:32:12.010 rapidly and so quickly, uh, in a lot of ways. So glad, glad we're digging 00:32:12.030 --> 00:32:12.770 in a little bit more. 00:32:13.370 --> 00:32:18.310 Um, okay, thank you both. I wanna, I wanna kinda shift again and get into Q&A. 00:32:18.320 --> 00:32:20.250 a little bit. So for folks on the other side, 00:32:21.090 --> 00:32:24.030 feel free to start to drop in some... I saw a couple come in. Don't mind 00:32:24.090 --> 00:32:26.950 me squinting as I'm trying to read the other screen here. A couple come in we'll 00:32:27.020 --> 00:32:30.990 hit in a second. Uh, as those are coming in, I guess, Duvall, Chris, just kinda wanna 00:32:31.030 --> 00:32:33.990 close with final thoughts, right? As we're moving towards 00:32:34.170 --> 00:32:38.990 more token, you know, centric, I don't wanna say necessarily token first 'cause I think 00:32:39.030 --> 00:32:43.750 a lot of this stuff kinda works in tandem, right? But ecosystem, what are some kind of, you know, immediate 00:32:43.770 --> 00:32:48.430 thoughts and takeaways for, for the folks on the other side? Chris, let's start with you. Yeah. So, so I'll 00:32:48.490 --> 00:32:52.990 jump in here, um, and, and just look at this maybe more from the issuer 00:32:53.130 --> 00:32:55.190 perspective, is 00:32:55.770 --> 00:32:58.430 I, I think we have historically had a lot of issues 00:32:58.470 --> 00:33:06.059 with d-decisioning system and deci-decisioning model fragmentation at a lot of issuers, particularly mid-size and 00:33:06.059 --> 00:33:06.940 large issuers. 00:33:07.530 --> 00:33:12.140 Um, you know, we did some studies now going back three years ago, but, you know, it still tells 00:33:12.190 --> 00:33:13.059 a really interesting 00:33:13.130 --> 00:33:20.150 story where, you know, we've, we've seen some large issuers that had three, four, five, in one instance, 00:33:20.210 --> 00:33:26.210 and a large issuer that had twenty-seven different ACS systems and different fragmentations 00:33:26.230 --> 00:33:34.119 and models, um, making decisions behind the scenes there. So, so I think historically we've had this challenge of, of 00:33:34.130 --> 00:33:36.970 decisioning model fragmentation just in the three DS. 00:33:37.050 --> 00:33:45.910 world, and, now you introduce tokenization into this, and very often, you know, that. is, perhaps handled by, uh, 00:33:45.910 --> 00:33:48.970 the, the risk model that's attached to the authorization engine, 00:33:49.090 --> 00:33:54.130 for example, and not actually as part of the, the three DS, the ACS or the three DS 00:33:54.490 --> 00:33:55.070 decisioning 00:33:55.190 --> 00:33:58.010 engine. Um, so, so this perhaps, it 00:33:58.430 --> 00:34:03.130 introduces even more fragmentation in modeling and decisioning. So, 00:34:03.570 --> 00:34:10.710 you know, our advice to issuers is always, you know, you should be on a path to, to working toward 00:34:10.770 --> 00:34:16.389 consolidated, uh, decisioning models, risk models as, as best as possible. 00:34:16.969 --> 00:34:24.070 We talked about it mostly within the, the context of three DS, uh, three, four, five, six years ago. Now 00:34:24.090 --> 00:34:29.090 we're talking about it in the context of three DS plus typical authentication, decisions, 00:34:29.590 --> 00:34:32.179 plus tokenization in that. as 00:34:32.210 --> 00:34:36.000 well. So, um, you know, fragmentation of these decision, 00:34:36.310 --> 00:34:38.250 decisioning systems that we've been talking about 00:34:38.929 --> 00:34:42.170 doesn't help any of these issues that we've identified earlier. 00:34:43.590 --> 00:34:43.730 Hmm. 00:34:44.469 --> 00:34:49.050 Thanks. Thanks, Chris. Uh, if I'm waiting for our marketing team after when you dropped that line of 00:34:49.110 --> 00:34:52.989 the, uh, one issuer having twenty-seven different- Yeah. Yeah. Yeah ... I don't know if you both Duvall 00:34:53.010 --> 00:34:56.909 and I, our eyebrows went straight up. That's, that's wild. Yeah. That's a lot . No, it's crazy, right? We' 00:34:56.920 --> 00:34:59.270 see this as a meme with all our eyebrows raised. 00:34:59.870 --> 00:35:01.020 Yeah. Uh, Duvall, 00:35:01.020 --> 00:35:01.800 any closing thoughts? 00:35:03.230 --> 00:35:05.890 Yeah, no, first of all, wow, you know, 00:35:05.890 --> 00:35:10.030 I, I, I guess to, to Chris' point, that, that issuer, you know, it's like one of the ACS 00:35:10.070 --> 00:35:14.090 for every day of the month almost, right? It's, uh, that's really interesting. But no, 00:35:14.590 --> 00:35:14.990 I, I think, 00:35:15.230 --> 00:35:15.410 um, 00:35:16.110 --> 00:35:20.810 I think it's, it's-- if, if you look at kind of where, where things are going, um, 00:35:21.030 --> 00:35:22.210 you know, closing 00:35:23.150 --> 00:35:23.410 thoughts 00:35:23.450 --> 00:35:28.170 would be, I think we need to, to, to, to modernize our approach a little 00:35:28.210 --> 00:35:32.990 bit, uh, you know, when it comes to this. As, as tokens, um, are, you know, there, 00:35:33.030 --> 00:35:35.890 there are a lot of these new tools available 00:35:36.010 --> 00:35:41.120 and, um, investing in making sure that we actually use those tools in the correct way 00:35:41.970 --> 00:35:46.430 is something that, that I think is, is gonna be very important here, right? How do you, 00:35:46.490 --> 00:35:47.960 how do you issue tokens in a, 00:35:48.190 --> 00:35:52.020 in a, in a, you know, in the correct way that, you know, you benefit from it on 00:35:52.050 --> 00:35:54.990 the, uh, you know, on the authorization side? How do you, 00:35:55.110 --> 00:36:02.220 um, you know, process data signals and identity signals, uh, together with these signals in a, in a way that 00:36:02.290 --> 00:36:05.310 actually enables you to, to make faster decisions? 00:36:05.350 --> 00:36:08.050 So I think a long way of 00:36:08.070 --> 00:36:08.790 saying, you know, 00:36:09.510 --> 00:36:14.970 really thinking about using the, the new capabilities of the tool, so upgrading your approach 00:36:15.050 --> 00:36:21.118 to it. I think we seeA lot of the market kind of being stuck in the, in the past, right? 00:36:21.198 --> 00:36:25.058 And, and, and in terms of kind of using the new tools in the old 00:36:25.178 --> 00:36:30.158 way. And I think that's perhaps the shift that we kinda need to make is to kind of use 00:36:30.698 --> 00:36:34.018 the new capabilities that are at our disposal. That's probably the biggest shift that we 00:36:34.038 --> 00:36:39.038 need to do, uh, because the tools are there, uh, but I just don't think we're using them in 00:36:39.058 --> 00:36:41.058 the right way just yet. Mm-hmm. 00:36:41.318 --> 00:36:43.218 Mm-hmm. Agreed. Agreed. 00:36:43.918 --> 00:36:44.318 Um, 00:36:44.558 --> 00:36:47.038 okay. Just let's roll into Q&A a little bit. 00:36:47.058 --> 00:36:51.378 It looks like, uh, Catherine, I think, Chris, you touched on, you answered one of the questions right in your, 00:36:51.498 --> 00:36:56.078 your final closing there. So it sounds like Catherine, that question on fragmentation got answered. That's 00:36:56.138 --> 00:36:58.018 awesome. Thank you. A 00:36:58.358 --> 00:37:03.988 couple others that rolled in here. So there's one about kind of piloting data or 00:37:04.038 --> 00:37:12.408 like how, how-- what's the recommendations of rolling out a data-only kind of approach? Is it specific merchant categories or 00:37:12.458 --> 00:37:17.018 is there a better, uh, better way to approach across all merchants? 00:37:17.078 --> 00:37:19.998 I don't know. Dewald, do you maybe wanna take that one 00:37:20.038 --> 00:37:25.158 in terms of... Sure. And, and, yeah, I mean, I'd love to also kinda hear from Jessica. I know Chris, 00:37:25.198 --> 00:37:28.938 is, also very, from a merchant perspective, very, very well, informed. But I, I, I, think in 00:37:29.038 --> 00:37:33.078 general, um, it's, it's probably, it's probably 00:37:33.218 --> 00:37:33.798 good to, 00:37:34.158 --> 00:37:39.648 to, um, from a, from a data-only perspective, right? If you're gonna start to kinda use a tool like that, 00:37:39.818 --> 00:37:42.278 which is, uh, and just to kind of quickly 00:37:42.358 --> 00:37:45.198 re, you know, re-resummarize that' or restate 00:37:45.238 --> 00:37:51.038 that. You've got-- with something like data-only, you've got the ability as a merchant to send the data elements like 00:37:51.078 --> 00:37:52.018 you would for three secure, 00:37:52.618 --> 00:37:57.278 but the issuer is not able to challenge, right? So. there's no risk that the, the issuer will challenge, 00:37:57.678 --> 00:38:01.478 but they get the data and are-- they're able to actually, you know, process 00:38:01.578 --> 00:38:03.998 that, um, and, and, and make sure that they 00:38:04.058 --> 00:38:06.218 then actually, uh, you know, use that, 00:38:06.698 --> 00:38:12.038 uh, as part of their authorization decisioning, right? Because that you'll get, uh, something like a cryptogram back in the 00:38:12.098 --> 00:38:17.068 same way that you can kind of submit to, to signal to the authorization side that, you know, this has, 00:38:17.258 --> 00:38:18.018 this has kind of been 00:38:18.058 --> 00:38:18.758 seen before. 00:38:19.378 --> 00:38:21.958 Now, uh, i-in terms of the approach around 00:38:22.018 --> 00:38:23.038 that, uh, 00:38:23.538 --> 00:38:28.018 I mean, you know, you could probably, if, if you wanted to just test that, you could probably limit 00:38:28.078 --> 00:38:32.518 it to... There, there's a couple of approaches, limit it to a specific BIN range, to a specific issuer. 00:38:32.578 --> 00:38:32.698 Yeah. 00:38:33.038 --> 00:38:35.238 You know, kind of test that to see, 00:38:35.358 --> 00:38:39.828 to see... I, I would probably recommend, um, if you, if you really wanna test it, 00:38:40.018 --> 00:38:42.978 um, you know, if, if you're coming from, uh, the 00:38:43.038 --> 00:38:43.818 side of a merchant, 00:38:44.538 --> 00:38:46.978 you know, pick one of your, your issuers that you 00:38:47.078 --> 00:38:51.058 partner with well and, and kind of work with them to say, "Right, okay, listen, hey, we're gonna 00:38:51.098 --> 00:38:56.028 send this to you, um, and let's, let's kind of collaborate on this." I think that's the thing with payments, 00:38:56.078 --> 00:38:57.418 is payments has two sides. 00:38:58.018 --> 00:38:59.118 And if we kind of, 00:38:59.178 --> 00:39:04.238 you know... There, there's a collaboration there that's required. And so I would, I would kind of recommend 00:39:04.638 --> 00:39:05.038 if you wanna 00:39:05.178 --> 00:39:08.958 pilot it, you know, choose, choose one of your issuer partners 00:39:09.038 --> 00:39:15.218 and, you know, put it to the test and, and, and prove the outcome. And then, you know, once 00:39:15.258 --> 00:39:16.058 you've kind of ironed out the 00:39:16.138 --> 00:39:16.478 kinks, 00:39:17.058 --> 00:39:19.108 go wider. De-Dewald, 00:39:19.178 --> 00:39:22.258 you, you, you hit on with that point exactly what I was gonna say 00:39:22.558 --> 00:39:22.828 is, 00:39:23.338 --> 00:39:25.398 I guess the broader point here 00:39:25.518 --> 00:39:32.118 is data-only is only as good as what the issuer does with it on the receiving end, 00:39:32.598 --> 00:39:32.858 right? 00:39:32.858 --> 00:39:40.118 Correct. So if you are kind of just blindly creating some sort of AB test or so-something along those lines 00:39:40.158 --> 00:39:46.178 and, and you don't have full visibility to how the issuer is actually u-using that 00:39:46.238 --> 00:39:52.018 data, um, then it's tough to really make a judgment as to how effective the, the-- how the impact is 00:39:52.058 --> 00:39:57.158 there. You don't see the full picture. So if you, um, as Dewald said, is if you do have 00:39:57.278 --> 00:40:02.998 a, a friendly issuer that you could work with on this, that's gonna get you more of the visibility 00:40:03.038 --> 00:40:09.388 to try to figure out h-how it's improving overall performance or where your data needs to be enhanced or things 00:40:09.418 --> 00:40:13.118 along those lines. Right on. Thank you, gentlemen. 00:40:13.678 --> 00:40:15.118 Um, there's two other questions here, but 00:40:18.458 --> 00:40:19.488 any thoughts, 00:40:19.678 --> 00:40:31.178 uh, any thoughts on how well orchestrators or PSPs are handling these nuances with tokenization and three 00:40:31.218 --> 00:40:31.598 DS? 00:40:33.058 --> 00:40:38.537 Yeah, I, I could, I could jump on that. So, you know, the term orchestrator, 00:40:38.838 --> 00:40:38.998 right, 00:40:39.398 --> 00:40:39.528 there, 00:40:39.898 --> 00:40:44.658 there's really a broad set of capabilities amongst orchestration platforms 00:40:45.238 --> 00:40:52.098 today, whether they be independent orchestration platforms that exist along the lines of like a Spreedly or a Gravy 00:40:52.158 --> 00:40:59.678 or something along those lines, or orchestration capabilities that exist within your PSP. And that is a model that is 00:40:59.718 --> 00:41:00.958 continuing to, 00:41:01.078 --> 00:41:02.598 um, uh, become 00:41:02.898 --> 00:41:09.198 sort of more and more prevalent in, in use these days. But the capabilities, uh, in each of those tends 00:41:09.238 --> 00:41:17.178 to vary greatly. Some of the orchestrators ha-have fairly limited capabilities, you know, just maybe being able to specify 00:41:17.198 --> 00:41:25.218 a simple workflow. Others start to get very advanced in regards to performance monitoring, cost monitoring, et cetera, 00:41:25.558 --> 00:41:28.558 that can be used as an input to your orchestration 00:41:28.978 --> 00:41:29.598 de-decision. 00:41:30.178 --> 00:41:30.298 Um, 00:41:30.598 --> 00:41:32.358 most orchestrators now 00:41:32.458 --> 00:41:32.888 are at-- 00:41:33.258 --> 00:41:35.058 the, uh, especially the standalone 00:41:35.098 --> 00:41:37.278 orchestrators are incorporating 00:41:37.758 --> 00:41:40.278 to- both tokenization and three DS 00:41:40.698 --> 00:41:42.298 into the capability 00:41:42.358 --> 00:41:49.348 logic, um, some of them a little better than others. So if, if you're evaluating orchestration capabilities, 00:41:49.798 --> 00:41:56.448 those are two areas you really wanna focus, on, like does the orchestrator actually take issuer level tokenization 00:41:56.478 --> 00:41:57.138 and three DS 00:41:57.158 --> 00:42:01.398 performance into account in, in making the orchestration decision, 00:42:01.898 --> 00:42:06.528 um, would be a good question to ask. So I guess short answer is we're seeing a variety 00:42:06.598 --> 00:42:07.268 of different approaches 00:42:07.418 --> 00:42:14.038 to this. It's continuing to mature. But in general, we're seeing most of these platforms take tokenization and three DS 00:42:14.078 --> 00:42:16.018 secure into consideration within 00:42:16.058 --> 00:42:21.186 their feature set. Awesome. Thanks, Chris. Uh, one more that just came in, and then there's a couple others. 00:42:21.206 --> 00:42:24.206 The others are a little bit more technical and specific to some, 00:42:24.226 --> 00:42:30.006 some I think individuals and accounts, so we'll, we'll follow up with those folks off. But, uh, throw this one 00:42:30.086 --> 00:42:36.786 out. Uh, can you talk about intermediary services such as MDES or VTS and how they can be leveraged in 00:42:36.846 --> 00:42:41.086 a data-only pilot? That adds some complexity in some cases. 00:42:43.626 --> 00:42:48.326 Yeah. I, I'm not really sure. I don't know, Dewaldt, if you have any insight into this, how 00:42:48.366 --> 00:42:50.046 they're sort of, uh, playing this. 00:42:51.486 --> 00:42:53.386 Yeah. And, and, and, and, and certainly, 00:42:53.486 --> 00:42:53.726 uh, 00:42:54.146 --> 00:42:57.216 I, I guess when it comes to, to, to those two services, 00:42:57.446 --> 00:43:03.006 um, you know, that, that, those, uh, MDES is obviously Mastercard's kind of tokenization service and VTS kind 00:43:03.046 --> 00:43:05.146 of being Visa's, uh, tokenization service. 00:43:05.286 --> 00:43:05.386 Um, 00:43:06.066 --> 00:43:07.106 and so I think, 00:43:07.226 --> 00:43:14.146 um, it'll be interesting to kinda see, um, exactly what, what complexity, um, there can be. But at 00:43:14.166 --> 00:43:17.146 the end of the day, um, when it comes to, to, um, 00:43:17.726 --> 00:43:18.026 sending 00:43:18.046 --> 00:43:19.086 some of the, the, 00:43:19.346 --> 00:43:21.745 the data a-a-across, 00:43:22.826 --> 00:43:27.046 it shouldn't necessarily be that it's, uh, that it's more complex. From a three secure 00:43:27.086 --> 00:43:32.206 perspective, uh, if you're using a token, um, what would happen is 00:43:32.406 --> 00:43:32.806 that, 00:43:33.306 --> 00:43:34.046 you know, a 00:43:34.086 --> 00:43:39.086 PAN or the, or a token in this case, right, uh, that you're sending kind of in that three secure 00:43:39.126 --> 00:43:43.026 message, uh, or that data-only message over to, uh, the issuer, 00:43:43.626 --> 00:43:47.976 um, you know, that would be in the middle by, uh, Mastercard or Visa. They would 00:43:48.026 --> 00:43:48.126 kind 00:43:48.166 --> 00:43:52.146 of like, you know, swap that out with the actual kind of PAN before it goes 00:43:52.686 --> 00:43:54.986 to the issuer side. And so when the issuer kinda 00:43:55.026 --> 00:44:00.526 sees that, they, they'll kind of, you know, be able to, to translate it back to the, the actual card 00:44:00.606 --> 00:44:04.186 that, that sits, that, that F-PAN kind of that I mentioned earlier, right, that, that sits behind 00:44:04.246 --> 00:44:06.186 that token. And so there, 00:44:06.256 --> 00:44:08.306 there shouldn't necessarily 00:44:08.346 --> 00:44:13.846 be, you know, any, any, uh, let's say, kinks in, in, in that process, but I, I know obviously sometimes 00:44:13.906 --> 00:44:18.166 it's, it, it might be a bit more complex than that. So Catherine, I'm not exactly sure whether 00:44:18.186 --> 00:44:19.826 there's- We'll have to dig in on there from a- 00:44:20.026 --> 00:44:24.916 Yes. That's definitely a question for your Mastercard and Visa rep, but, but I guess, Dewaldt, what we can 00:44:25.026 --> 00:44:30.826 say is we know that both Mastercard and Visa are paying a lot of attention this year, twenty twenty-six into 00:44:30.866 --> 00:44:31.046 twenty 00:44:31.126 --> 00:44:33.036 twenty-seven, into data only, 00:44:33.486 --> 00:44:39.166 right? So I'm, I, you know, I, I would suspect that they are thinking through these issues here. 00:44:39.766 --> 00:44:43.126 Um, and it's-- and I-I-I would also suspect they'd be very 00:44:43.206 --> 00:44:49.986 happy to speak to any issuer or any merchant who wants to talk to them about using data-only rails. They, 00:44:50.066 --> 00:44:52.126 they would pick up the phone in a minute a-on 00:44:52.166 --> 00:44:54.506 this topic. Absolutely. 00:44:55.366 --> 00:45:01.106 Uh, Dewaldt, Chris, thank you so much. Uh, enjoyed the conversation today. To everyone on the other side, thank you. 00:45:01.246 --> 00:45:05.986 Just a couple quick closing things too. Again, if, uh, y'all haven't caught the white paper, that will 00:45:06.026 --> 00:45:11.406 go out. And I believe, Chris, Dewaldt, we have kind of a third part of this, uh, maybe later in 00:45:11.486 --> 00:45:13.946 April where there's a conversation with Stripe coming up 00:45:14.006 --> 00:45:18.246 on some of these similar, similar topics- Yeah ... and narratives. So, uh- Yeah ... keep an eye out everyone 00:45:18.306 --> 00:45:22.366 for that. Looking forward to it. Yeah. For sure. Yep. Uh, so that'll be coming down the pipe as well. 00:45:22.555 --> 00:45:23.946 And, uh, thank you. Thank you both. 00:45:24.026 --> 00:45:26.046 Appreciate it. Great. Thanks, Max. Thank 00:45:26.046 --> 00:45:27.966 you. Thanks, everyone. Thanks, all. Thanks, everyone. Have a wonderful 00:45:28.026 --> 00:45:28.365 weekend.", "publisher": { "@type": "Organization", "name": "Entersekt", "url": "https://www.entersekt.com/" } }
Mastering the Interplay of Tokenization and 3-D Secure
Explore this on-demand webinar to learn how tokenization and EMV 3-D Secure (3DS) are converging to improve fraud prevention, authentication, and authorization. Chris Uriarte from Glenbrook Partners and Dewald Nolte from Entersekt unpack why tokenization alone does not solve for identity, how richer data supports better risk-based decisioning, and why 3DS should be viewed as more than a compliance requirement.
The session also covers practical ways to reduce false declines, improve approval rates, and deliver lower-friction digital payment experiences. If you’re focused on strengthening card-not-present (CNP) fraud controls while protecting customer experience, this recording offers a useful view of where secure commerce is headed.
Highlights
- Why tokenization and 3DS work best as a layered approach to credential and identity protection
- How better data quality improves issuer decisioning, approval rates, and fraud outcomes
- What merchants and issuers can do to reduce false declines and unnecessary checkout friction
- How data-only strategies can support smarter authentication and authorization decisions
- Why these trends matter as digital commerce evolves toward wallet-first and agentic experiences
Want to dive deeper? Download the companion white paper for a closer look at the convergence of tokenization and 3-D Secure.
