So requirement 3, all about the storage and encryption of cardholder data,
and I know, Jacob, we could probably spend a day talking about encryption,
because it's like both of our favorite topics.
It is.
Right, so we're not going to do that.
No, let's not.
So I'm going to start off with a really [00:41: 49.000 ] simple question.
For most merchants, not service providers,
they shouldn't be storing cardholder data anyway.
Probably not.
Why on earth are people still wanting to hold onto cardholder data?
It's about, you know, this requirement is about reducing the attack footprint.
If you don't have cardholder data, no one can steal it from you.
Right.
So do you still have clients that keep cardholder data?
There are some clients that still keep cardholder data.
I'd say more and more merchants are sort of wising to this idea and saying,
I don't want it, right?
I don't want to deal with the cryptographic sort of nonsense; I
don't want to deal with the storage nonsense.
I don't want to deal with the data disposal stuff.
I can make the payment processor do all of that for me,
and I can get some tokens or I can just not have it,
and I want to do that.
Where I see large merchants continuing to hang on to payment card
data is when they have sort of legacy functions,
right?
And maybe legacy arrangements with their payment processing entity,
where sort of un-pinning that and going to an agreement where
the payment processor does some tokenization.
I guess, I don't know, right?
I'm not privy to their contracts, but it could be significant.
So they might be doing authorization and then doing their
own clearing and capture files themselves,
those types of arrangements?
Potentially, right, right,
or just where the agreement is just the payment processing service and you know,
oh, the tokenization would be an add-on or something like that,
and they're reluctant to go down that road.