Consent Life Cycle Management

Thanks for coming. It's it's been a long day. I probably presume so. And you've been hearing a lot of what say identity consent, GDPR PST two, and then the big new two new regulations like PST two and GDPR came in this first of this year and people are busy working on it. I'm not sure how many of you come from financial industry, but everyone is a banking customer, I would say. So let's start looking from that aspect and then see, what, how is your financial banking experience going to change in the coming years?

Have the regulators got things right in a way so that it is one of the, if I look from open banking in UK or in Europe, it's a lot of complexity in terms of security architecture, because they wanted to make sure it's secure by design as well and privacy by design. So I'll just go over some of the introductions. Recently, we have seen lot of PSC, two and GDPR talks and lot of marketing material, and lot of emails we are changing. Are you willing to be in the system?

Yes, no. All of this. And some customers went for data, subject access requests, and a lot of these things are happening. PST two is more about sharing data about customer in the FinTech industry, to the FinTech industry. So the regulators want to bring competition. Okay. That's the main objective. Maybe some people used to say, no, it's all about squashing or kind of crippling out visa, MasterCard companies. Yes.

In a way, but still it's, it's more about competition. Whether the customers are getting their value for money or is the banking industry, has it, has it evolved or did it have any innovations? We are still used to the same old banking.

You go, do you have done through numerous banking channels from, in a branch to a phone to internet mobile, and now comes to API. This is the API channel. You can think of it as an API channel. And then that's, that's where it's, it's in the API channel and it's in the API ecosystem. The competition is going to come from the FinTech industries who are very nimble, agile and solve a lot of the customers, paying problems, unlike the banks, which give a lot of problems to the customers that, that we are kind of in a stuck up situation. So is it all about consent? Yes. No.

Then what is it all, why are we all talking about this? It's just, yes, no, I give, not give. Okay. That's how it looks. Yes. Or at a high level.

Well, let's, I want to kind of take you through that kind of a journey where it starts and what is the implications and what are the complications coming out of this? That's probably my focus of today. So this is the landscape. So if anyone didn't come from a financial industry or banking industry, even a lot of customers in Europe doesn't know about PST two or open banking, not none of those ones.

They're, they're just saying skeptical about, we're not sure if this will work, we don't want it. Or we will try. There are usually some early adopters, like the age group of 30 to 40, they, they will just say, oh, I will adopt it. And then it kind of goes in and then others will pick it up. If it becomes a norm, like when WhatsApp was coming out, we said, oh, WhatsApp, no, I'm not using it. Okay. Now my mom uses WhatsApp to call me and she never even know how to call phone or browse. She goes to WhatsApp, clicks that button and calls me. So that's a technology enablement and that's coming.

And if people realize that there is a value, they will surely adopt. So here you have bit of a terminology. So might be somewhere. You might see what is PSE is a customer, just a customer, TPP, FinTech, or fun call as PSP.

So just, these are the acronyms we always use in PST two or open banking. And then there is consent and authorization, to be honest, not many people, even in the banking industry or the fellow colleagues of me. I worked in a larger three major banks in the last two years, only on the PSB two. When we talk about consent and authorization, not many people get the hang of it and say, yes, consent management. I'm building a consent management module. Okay. Let's start again. Okay. You'd asked to come from whether are you consenting it or authorizing it?

A lot of this is the terminology and don't people don't get it. They understand it in principle. Yes. I want to share something that I concerned. Yes. Actually the consent starts at the FinTech say FinTech has got some services and it's saying, I want to take your data to give you some service. So it's asking you for consent early on that I wanted to use your banking data. Hasn't got this banking data, but it says I want, and you say yes. Okay. Now the FinTech says, okay, you said, okay, but I don't have raw material somewhere. I have to go and get this your banking data. Okay.

I'll go to the bank and get the data. Okay. That's the data. And you authorize at the bank. Okay. And people might be thinking, okay, you, you do the authorization in the bank and you do the authorization management in the bank. Yes. And that's what we call it. But we just use it interchangeably, concern, management, authorization, management, whatever.

Again, bank can still go ahead and say, do you consent to share this? They can create a new consent agreement as well, but it's not needed as per PST two, but they could still do it if they really want to do it for some reason. Okay. But also does the bank have to check the consent agreement that you have given to the TPP? Which means TPP has said, I'm going to use your banking, transaction data to give you some advice to manage your finance. Okay. You might have an agreement, some micro prints and all of that.

Some kind of agreement you say, yes, you don't even read you say yes and go forward. But do the bank have the responsibility to go and check or view that consent agreement recently?

EBA said, no, you don't have to do that. You just say, if, if it's a regulated entity, if they're coming to ask data, just give it don't, don't go double check. If they have a consent or not. So that these are the kind of small, small complexities or legal issues that coming out. And someone has to come and give an advisory or a guideline to go about this. And finally bank has the authorizations of sharing the data to that. And then you can go and revoke this thing. So if I just change into another perspective, sorry, if I just change into another perspective, it's something like this.

So TPP says, I want a request data. Then it goes into authorized mode. These are kind of a modes of operation. Then after that, you say, okay, I've, I've authorized it. Okay. Then you can go into two other ways. Then you have to expire or you can, you can renew and keep it in authorization state, or you would have to it'll expire. So it's more like, not something that we have all been used to in the worlds of login with Google login, with Facebook, all of that, which means you give one time authorization. And the data is stuck with, with the service provider for time unknown. Okay.

So your profile, I don't know how many of you clean up your Google permission? Like if you have a Google account and if you have logged in with Google, which I usually do, if you go into something like account dot, google.com/permission, something like that. And you can see where all you have shared. Okay. If you you'll be surprised, if you go there, you'll see, like, you'll be surprised that I had somewhere 50 to 70 when I looked at it first time and we always say, oh, log it with Google. Fine. Then you'll end up with a lot of this.

And these guys are having your data and there is no kind of a governance. How long can you have it? Who can access it? Who got breached?

And we, we have all seen this breaches right in the black market. Everyone's identity is available in the black market for peanut price. So that's how it's all happening. So the regulator said, this is the problem. Okay. How do we fix it? So we gave, so PST two is also governed by GDPR as well. Okay. You need to have data minimization and you have to have your definite period of expiry as well. You can't keep someone's data for time unknown. So you'll expire or you can go and rework and say, I'm not really, I don't really want to share this.

And then you get this in the banks or in any service. So in the banks, you will say, if you log into internet banking, you say, oh, we are sharing your data with these players. Do you want it to rework or just leave it? Then that's your choice. Then you can rework it. That is an option. And then you finish up that. So this looks simple, simple use case fine. Then in one of the complexity slides, I will say what happens and where we end up in a zombie state and data. Okay. So it's a level one level one. This is a bit of a level three.

I don't want to kind of go through this, but at least some block diagrams. So you start somewhere on the TPP side and you say, I want data. You do first factor authentication, second factor authentication, or give your consent authorization. And then the TPP says, oh, I got your authentication code or access token in what world I can start getting your data. So you give the authentication code and get the data back. So this is the normal scenario. But then the, the main thing is something is called the dynamic, linking that regulators brought in into the RTS specification.

If anyone is following it, that's where you, you provide the integrity of what you're doing and what you're consenting. And so you would probably start with a consent somewhere and say, someone wants to take your data. And then it has all of this data there. If one changes, okay, that authentication code should no longer be valid. So that code that is issued here should have some ingredients of every little thing. It's like a small micro Legos you put together and build a bigger block. That bigger block is the access token. If you and change something that access token should not be valid.

So that's how they kind of said, this is first week to that request. And it's governed by certain issue once criteria, which means this is issued to this TPP to access it, this kind of information at this time, period, this frequency, if any of this is changed, it's a contract. Okay? So if that contract is kind of changed, then that token is no longer valid. So if a TPP tomorrow sends something else, it's the same token, but asked for some other extra information, then banks will say no. So this is a bit of a where the dynamic linking goes into this.

And a lot of the securities, the two factor authentication providers have difficulty catering for the dynamic linking, for instance, if you're using a T OTP, where does T OTP have any of this information in Grantly? Especially an amount on the payee?

No, it's just, but there is a solution. If they fix their algorithm, they can claim we are dynamic linking complaint, but it's not anyway, let's move on. Okay. So what's implications. Okay. Let's kind of ask these questions and right. Who can ask consent and authorization eventually is regulated TPPs so it's not like wide open public infrastructure. Anybody can ask. So if someone is coming and asking the bank or, or the customers, they have to be regulated. So there is a condition that says it has to take place in this regulated environment.

And the TPP should be registered with FCA for UK, or there's a lot of all the nation and competent authorities. All the European union nations have some kind of financial contact authority bodies. They should be registered there. They should have a license there. And anyway, that's the double checking of consent because it is a regulated, EBA said, you don't have to check the consent anyway. So how to request then there is a, again, another technological complexity inside.

It's not a complexity in a way for security people, but there are so many smaller fintechs and fintechs or coming like, and thinking like, oh, I can think of an idea and build it overnight. Or in, let's say two months or two weeks time. And that's probably not going to happen because you need to kind of cater to the security framework. And by the time you fix this, you, you probably looking at a big chunk of money in investment to build this kind of architecture. So you need to be registered and you need to have a AI dash or any other certificates, then how to authorize consent.

So when you wanted to go and get authorization, the strong customer authentication kicks in. So there is a, I don't want to keep boring with a strong customer or multi multifactor authentication.

It's, it's kind of a comprehensive study and conditions that say, you have to do this to get CA compliant and you probably can bring in an auditor to review your infrastructure and then the dynamic linking and how do you regulate? So the data sharing, how do you regulate?

So, like I said, it's a policies, some kind of policies. What is the issue once criteria? When did we do this? What did we do this for? And all of this, or kind of captured in log. So you'll have traceability in audit as well. Okay. How do you rework? So you can work from any banking, existing banking channels. So internet banking, telephone banking go to a branch or a call phone, and you should be able to revoke your consent.

The main problem in all the major banks that we I have worked, or we have worked is, is how do you bring this consent information into all of these banking channels so that a customer support officer can take the call and cancel it, cancel or work for someone else behalf and PST two. And GDPR comes in that there as well and say, why is this customer support personal asking for data birth? Okay. There is a breach aspect there. Did we do that?

Are we going to bring in a strong customer authentication to make sure the customer did a simple push notification or biometric on his phone answer to the customer support personal and said, oh, I'm authenticated. Now you work it. Okay. That kind of things. So it is a bit of a, a tricky sticky situation. And then you could also go to the FinTech and say, I don't want to use your app anymore. And that's it I want to get done with. So if you uninstall, or if you go and change your permission, then all your data has to be kind of deleted.

And then that consent has to be flown back into banking infrastructure. So the bank keeps a track of it as well. So it's not like auto expire kind of a, a situation. They have to tell the banks that yes, this customer doesn't want to use my application. And this are the concerns and authorizations he has given, and we want to cancel it. And when does life end? So there is 90 days in PST, two kind of a frame, the RTS specification, or renewed with new authorization.

So if you want to renew again, you again, go through a new set of authorization flow, which involves strong customer authentication, dynamic thinking all of that. Okay. Okay. So let's yeah, these are all usual ones. I don't pretty much, you might known it already, maybe refreshing and stuff. And bit of a complications will come. What about joint customer accounts? Okay. So family has an account. So in order for someone to authorize, can one person do it, do they have the legal paperwork to act on their behalf? Like power of attorney kind of aspect.

And if you don't have that, then there's, so banks are saying, oh, two of them have to authorize it. Okay. Then who reworks it? Okay. Okay. Both of them have to work it. What if one wants rework it, one wants to keep, because you, you probably see in a family situation, one wants to, how do you manage those ones?

And, or for instance, the couple had a diverse and say, oh, I wanted to leave this and bank account and all of this, how is this authorizations managed in that way? And all the big banks are still kind of struggling to get an answer and they will have a lot of legal work to complete. And what about the compound consent? I'll probably start with a simple example. Let's say I wanted to have a gym membership or any, any membership in, in a way. So they want to do, they want to know my personal data. Okay. So banks can be an IDP as well.

They can provide identity, not within the PST two framework, but outside it, they can become an identity provider. So you might get your name or address, phone number, whatever. And then you wanted to say, I'm running a contract for 12 months. Then you say, okay, we are going to do a credit check on you because we are giving you a credit membership ruling. Okay. So if you're going to do a credit check, we need to know all your banking, transaction data, which is an AI role because they don't have to go in the new PSP world.

They don't have to go to Experian and kind of people to get a credit check. They can do a credit check based on your banking statements, which they have access to under the new licensing. So they will have an AI SP license. They will get the data. They will just, okay. Salary expenses, all of that. Okay. We can give you credit. Okay. That's a ASP license. Then they want to have a recurring payment. Okay. Which is every month you want to take money away from bank account, then it's a PSP license. So you have all these licenses. So they're acting in AI role PIs role.

And they're also talking under P GDPR data sharing with another party. It could be Google, or it could be bank, whatever. Would you have a compound consent, one consent, or would you just go and do one consent at every stage? And then when you want to revoke, you go and revoke consent at every stage, okay. Then it becomes a frictional journey or a user experience for a customer. And it'll be too many consents there waiting, given for gym membership, PIs, and then for pays, given for gym membership. And you cancel where, and you don't cancel other. And how do bank treat that?

So that that's more like a compound consent. What if DPP lose their license to operate? Okay. Let's say TPP loses for some money laundering or any, any of those things. That's usually most of the time you'll have a suspension coming on that. And if you, if you have that, how do you then handle that situation? Would they just delete all the data, being a good TPP and then tell the bank to say, Hey, we got our license revoked or suspended.

Can you, would you suspend a consent and authorization or would you, would you just delete it? Okay. So the simple solution is just deleted everything. Okay. But the TPP will say we got suspended for wrong administration problem. Okay. It's not our problem. I can prove it. But then it is our duty to tell you that we got suspended, but then you went and deleted all the consents. Given. Now I have to ask all my customer, like I might have a 2 million customer and then say, go back and run the consent cycle or authorization cycle.

Again, never happen. You'll have around more than 50% of dropouts. Okay. They will never give the data. So that's a kind of a FinTech unfriendly situation. Then what about the liability? Okay.

I give, I've done this strong customer authentication. I've done all of that. I've given the data to someone and my identity got breached. Okay. Is there going to be any liability for us? They need to know. And what if for a fraud, let's say someone, I know for a fact, a lot of banks are not going into strictly implementing strong customer authentication. They don't have time. Okay. Simple. They're still using SMS OTP. We just heard SMS is something you don't want to use.

But if there is a social engineering or social hacking, someone got into your O TPR stole your thing, and they did a completed fraudulent transaction. That's a big issue, but bank is li always liable from that aspect. And then on the data side, banks are not supposed to give any personal data, but the breach is always on the weakling of the TPPs because the bank has in money and they will protect their assets. And infrastructure is the TPP. Who's kind of a startup with three to five resources, but kind of a, a young team and doing it want to get to market quickly in all the possible shortcuts.

A good example is a LinkedIn. When LinkedIn started, it was a bunch of guys, they started and they was the worst security design in, in LinkedIn. They got breached passwords where in plain text, all of this, this is a nightmare scenario. So that's the FinTech is the weak link in this, in this ecosystem. If they got breached, how are we going to address the liability? Okay. So let's kind of quickly go over GDPR concerns as well. I don't want to keep telling the GDPR side, we have been hearing about it for like a year going on and on and on. And so I'll just quickly go to that point.

There FinTech is sharing with another FinTech. Okay. So they got PST to data. They want to share with another FinTech, but this time they're sharing. Why GDPR concern, not PSD two, it's a GDPR concern. And that FinTech is not regulated. It could be anyone in the market. Who's trying to do something it's, it's unsecure. After you can think of what do you do with that kind of a scenario.

And what if, if you revoke a consent on the banking system, the bank will tell the TPP, the first TPP first party TPP, but who's going to tell the second party TPP or the third party, actually, there's no one there to do. Do that. Will they keep the data or would they delete it? Would they check the consent? Do they have any framework to do that? And that's where you'll end up with a zombie state data who doesn't have any, they contract that back to the original. So anytime you go to a FinTech and say, you have my data, can you tell my source of my data?

Okay, we got it from this FinTech. Okay. You go to that FinTech. Okay. You shared my data to him. Where did you get the data?

Oh, you have given the consent on PST two. Well, I reworked that consent. What have we done with my data? So there is a lot of what is it? Unaddressed area and also fintechs in other jurisdictions, let's say one FinTech sharing to another FinTech. And that FinTech is not even in the European union and you'll have that problem. So there's a lot of legal problems there. Okay. That's that's it from me. Thank you. If you have questions, happy to answer. Thank.