Mastering the Interplay of Tokenization and 3-D Secure

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.