WEBVTT 00:00:07.160 --> 00:00:09.960 Hello, everyone. Thank you for joining us today. 00:00:10.120 --> 00:00:16.000 Um, exciting conversation ahead, I think, about tokenization and 3DS. Uh, an interesting one, a forward-looking one. 00:00:16.059 --> 00:00:21.830 for sure. And for those on the other side, again, kind of a carry on from, from what we had, 00:00:21.900 --> 00:00:25.900 uh, sent out in, uh, a white paper that Glenbrook and Intersect recently did on this topic. 00:00:26.080 --> 00:00:30.850 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.