Webinar: Strong Customer Authentication under GDPR and PSD2

Our webinar discussing the implication of customer authentication under the General Data Protection Rule and the Second Payment Services Directive. The first 30 minutes is the presentation with about 20 minutes of Q&A afterwards.

Transcript:

Yuriy Mikitchenko: Basically, for joining the ‘Messente’ webinar, discussing the general data protection rule and the second payment services directive. We'll be focusing on user authentication and star strong authentication requirements in this webinar, with providing an overview of the laws as well. I'd like to first introduce our panelists for this webinar. First, we have Raili Liiva. She is in our sales and market research departments. She's done a last, did a lot of research over the last few months over the payment services directive, that's going to be going in place next year.

Also, we have Uku Tomikas, he is our lead sales researcher has been studying the general data protection rule over the last few months as well. I’m Yuriy Mikitchenko, the head of marketing here in Messente. So, as I said, we'll have an overview of the two EU laws and we'll go deeper into the implications the laws have around user authentication and data protection. As well as user behavior online. So, one thing to keep in mind, as Eileen who are discussing the new laws is, how user behavior influences data protection rules and data protection overall as well as online security.

So, keep in mind of the things they implement the tools, you buy for your online services and how user behavior effects data protection. So, a couple of caveats want to let you guys know. We were not giving legal advice in this webinar. We are sharing what we know regarding the two laws that are going in place next year. We'll be opening things up for questions as well. We'll be able to answer the questions to the best of our ability. Also, if you looked in the GoToWebinar control panel on your screen, there is a place to ask questions.

It's about the second or third section for in the panel. So, if you have questions during the webinar, go ahead and type them in there. The three of us will try to answer them to the best of our abilities and it will also be going over some of the more pertinent questions at the very end. So, without further ado, if you are ready let's jump into the general data protection rule.

Uku Tomikas: Thanks, Yuriy and thanks everyone who's listening. To start off, I will give a brief overview of the main topics of the general data protection regulation. But I'm mainly covering the aspects that pertain to the importance of customer authentication under GDPR. To summarize in a nutshell just straight off, it’s the regulation states that in regards the data processing. Security measures have to be in place that are in accordance with the risks associated. So, if we're thinking about for example account hijacking or data theft, one of the measures to combat it is having a strong multi-layered customer authentication system in place.

To start, the general data protection regulation is a new piece of legislation coming into effect in 2018. It replaces a 1995 regulation. Both of the pieces of legislation we're talking about today, aim to updates and bring into accordance with the current era, the data handling and privacy questions that surround at the European Union and foreign companies handing EU citizen data. The key word here is EU citizens, because it doesn't matter if the company itself is a European company or for example a US company or wherever in the world.

If they're handling EU citizen data, these specific regulations applied to them. The general data protection regulation is a part of the collection of human rights laws of the year as well. I said, it applies to all European citizens. The definition of what personal data actually means that is covered under GDPR is less purposefully broad. So, the idea is that, any piece of data that a subject gives to a company and in directly or indirectly used to identify the data subject. So, we're talking about email addresses, browsing history, searches, IP addresses, phone numbers, cookies, you name it.

Anything that can be used to directly or indirectly identify the data subject is considered as personal data. There's also a specific category that comes into that, it's called ‘Special Personal data.’ This usually pertains through information that is very specific to a concrete person that can be used to damage that person significantly. So, we're mostly talking about biometric data for example. That if it gets leaked or gets breached can be used to not only hack accounts and hijack accounts, but can only be in addition used to steal identities. Which is one of the main ideas that they're doing here.

The purpose why this has been kept so broad is that, the previous document was in place for 23 years. So, the new document that is coming into place is designed to be in place for another 20 years. Even considering the rapid expansion of all technologies, all new ideas that are coming into play and all new features that are becoming available for more and more people and more and more hackers subsequently as well. That can be used to attack people and their accounts. This ultimately bring this into the first idea, the main broad idea that I'm going to talk about. Which is ‘Privacy by Design.’

Now ‘Privacy by Design’ is one of the core principles and one of the essential estates is that when you're actually designing systems, you need to build the security features into the process from the get-go. So, you have to have a system in place from the very beginning to make sure that all of your data gathering, handling, processing and then storage systems are already secure and that they're already taken care of. It also means that, you need to have a strong understanding of how the entire process of data moving their data handling is taken care of.

So, where do you store? How do you move it and what are the risks associated? You need to understand, if I'm taking some sort of data from people and then bouncing it through my service and then ending it up in some other server, God knows where. I need to understand whether the risk associated with it, where do I need to use different measures to make sure that the data doesn't lead and that there are no breaches. If there are breaches, that the breaches don't meet the significant damage to people.

To do that, you need to have something as a security information and event management system in place. Now a ‘SAM’ system is not a piece of software. It's more a set of principles or guidelines. That you can easily find on the web to understand development more broadly, because some more go into the details here. But essentially it means that you have a way of monitoring the entire, system monitoring data movement and monitoring very possible breach. Then and taking the necessary steps to make sure that any breaches are notified about first to the authorities, and then if the breaches is significant enough also putting that info in the hands of data subjects as well.

It's something that the especially the breach notifications have been very widely publicized and are a very big part of the topic itself. Now from moving on from ‘Privacy by Design,’ we get to ‘Consumer Rights’. Now we used to work in an opt-in situation rather an opt-out situation. Where for example, if somebody was registering their account for a website or for a service. You could leave a pre-ticked box saving, stating that the person would like to receive newsletters or marketing email for example.

Now under GDPR, there is a new definition for what consent is. It needs to be freely given, specific informed and explicit. So, it can no longer be deduced from inactivity or silence. Meaning that pre-ticked boxes are an out. It actually been one of the things that has been specifically brought out pre ticked boxes I mean in accompanying documents to the GDPR. Just to state how important that fact is. You need to be able as a company to verify that the person has given you consent.

This doesn't mean that, if you don't have consent that you have no right to handle data at all. There are still certain types of rights for companies that allow data processing. Such as for example legal requirements, when we were talking about for example telecom companies. Who have to keep customer data on their servers and keep it available for 5, 6 years; for example. When it pertains to anti-terrorism laws or certain tax laws or so on and so forth, as well as contractual obligations.

So, if you have a contract between you and your clients. In order to fulfill your contractual obligations, you need to handle the data, all the data subject in a certain manner. Then you're still allowed to do that even if the consent is withdrawn. You have the right to perform those actions in order to fulfill your contractual obligations, until the contract itself is nullified or taken aback or you end it or whatever else happens to it, to essentially cancel the contract in a sense. Until you have that right.

You can ask for consent, if you want to handle the data subject’s data in another way that isn't pursuant to the actual contract itself. So, if you want to send for example, newsletters that aren't important for filling the services or fulfilling the tasks that you have under the contract that you have with your clients. Then you can ask for consent to send them newsletters. Then once they decide to perhaps revoke it and you can send them the newsletters anymore, but you can still fill your contractual obligations. Which is one of the things that plays into that.

As before us the Data Protection Directive that that preceded the GDPR stated as well, subjects have the access the data that has been compiled upon them. Which is why subject data access request. These requests also need to be verified in a clear manner, as well as they have the right to be forgotten. So, essentially not only they have, do they have the right to have their data presented to them in a usable format. They also have the right to ask for the deletion of said data from that company's databases.

If they search see so fit unless, there are of course again as mentioned before legal requirements that prohibit the company to do so. One other new sort of right that has been really provided for the people is, the rights of data portability. What this essentially means is? You not only have the right to retrieve the data that you has been sort of compiled about you, but you also have the right to demand it to provide it to a another service provider. For example, your data that you have provided or for example have it given to you in a usable format. Then give it forward to another provider.

So, for example, let's take if you're on a social media platform like Facebook. You have the right to ask Facebook for the several thousand pages of data they have on, you, your friends list, your preferences, the pages you'd like, the pages you haven't liked, so on so forth. Yhe options that you have put in the app so on and so forth. You have the right to take that data and take it to another social media provider. Essentially giving you the ability to build a profile that would have taken you a long time and the network that whoever you taken you a long time, before it's you're built from scratch you can now build it up from the previous network that you had before.

Now the idea behind this is that, they're trying to in a sense get rid of a lot of customer lock in. So, customers no longer can be stuck on a platform or with a company, just simply because the reasons that their important information is on there or their friends are on there, your network is on there. So, they're trying to get rid of these lock ins and really change that up a little bit. This idea itself of changing ‘Customer rights’ and Privacy by Design’, brings us into another important part which is the ‘Shift of Liability.’

Now when previously people had a weak passport for example and their account got hacked and their data was stolen in a sense. In very many cases, it wasn't really anything that the company sort of need to do about. So, they weren't really liable for the damages that occurred, if the processes they had in place we're sort of strong enough. So, unless they were of course malicious for example, leaving malicious back doors to open ways for hackers and so on and so forth. But with the rise of things like social engineering nowadays. In which for example hackers don't no longer don't anymore he knew systems where they try to find backdoors or hack accounts or do anything like that.

They actually simply have to perform and call any number of companies. So, for example they call the utilities company and they want to find out a certain piece of information about a person. Be it an email address or a phone number or maybe it's like credit card detail, whatever it might be. They will try to cut a tiny fragment of information about a person. So, in order to do this, they might sometimes for example changed her voice with programs to a female voice. They will play in the background a voice of a baby crying, just to pull at the heartstrings if the person at the other end of the phone.

So, they can get tiny pieces of information in order to retrieve just a sliver. Once they do that, once they have this tiny piece of information, they use that information to get another piece of information from another place and so on and so forth. Then they have a very strong enough picture of the person we're talking about. Then they will use this information, so for example gain access to your bank account, your company's bank accounts, empty it. Encrypt your personal files, encrypt your company's files and then pretty much ransom them off to you in some other way or so on and so forth.

That essentially has driven the legislators themselves to build and to demand systems in which several different ways of protecting data are put into play. That means that also the liability has shifted to the companies. If you don't have the right processes in place, you're liable for not only the damages but also an amount of fines. So, they're our most severe fine right now by GDPR that you can sustain. Because of the breaches and if they're found to be strong enough or big enough or if you have been worth several times, for example is final 20 million euros or 4% of your yearly revenue. Which for anyone is a big chunk of change.

Now not only is it mandatory to verify consent clearly, but you also have to verify data access requests, very concretely. You have to have a good general overview of what you're doing. You also have to have the ability to restore the availability and access to personal data in a timely manner, in the event the physical or technical incident. If we're talking about having a second layer or authentication in place, it can be a very useful tool to maybe not always prevent people from sustaining damages. But they will have a way of quickly getting their personal data back for example.

Another part of it is actually having compliant partners. So, if we're using third-party providers who are processing their data for example or we're using third-party providers to provide a service for us, in which they are actually for producing some sort of a service for us. Handling our customer data, this will ultimately lead very sort of struggling to the part where we need to be aware that they are also compliant. So, our partners need to be compliant, because we're also liable if they handle our data.

So, to summarize, under the general data protection regulation having a sort of a multi-layered authentication system in place is a measure by which you can comply with ‘Privacy by Design.’ In that, you will build it in from the very beginning and have it in place to prevent the code hijacking and data theft. It also provides you a way of having a clear approval method of consent verification data, access request verification and subject data deletion request verification. As a partner for us for example, our compliance and use of systems that enable us to provide a compliant system who are customers is paramount as well.

So, having these things in place can help you greatly move towards being compliant and taking the necessary steps that can help you reach that point in time. That's it from my side, thanks guys.

Yuriy Mikitchenko: Awesome, thanks Uku. Now I’d like to pass it off to Raili to go over the ‘Payment Services Directive’, and the details around that as well as authentication requirements under this rule as well. So, Raili if you're ready go ahead and take over.

Raili Liiva: Yep, thanks Yuriy. It's really great to see if you have so many listeners with us today. So, thanks for joining us. So, for the starters as we all know then payment industry is currently undergoing significant transformation. Especially with advent of FinTech, which is now boost and get serious threat to the revenues and the customer bases of traditional financial institutions. To compound matters for banks in particular is the revised payment service directive.

It's actually at that time technology-based directive that aims to promote competition and innovation within the European payments market. As well as to improve the security for online payments and account access. It comes fully into effect in January 2018, when each of the European Union member countries and [INAUDIBLE 19:32] post directives Financial guidelines into their national laws. Many believe that, it could actually play a vital role in changing banking as we know it now.

The primary goal of this new directive is to create a single integrated market for payment services. Doing it by standardizing regulations for banks and for the new payment service providers, as well as we have started to see. By that I mean, internet banking, mobile backing apps, E-wallets and so on and so on and so on. As this innovative service providers were not regulated by the PCT. It was time to make some changes and what was lacking in the first directive is actually now covered by the second. For example, under the first directed the last parents and conduct of business requirements applied only to those transactions were booked.

The payer and recipient sites were located in the you and where the payments was made in Euros or another member state currencies. Basically, 2 actually extends this directives, geographical scope to include transactions for only one side is located in the EU. As well it will also include transactions in non-EU currencies. So, in to ensure transparency and fair competition and it will actually break down the barriers for the new payment services 2. This is something that will definitely benefit the customers.

These 2 new service providers that will be entering the market are thirsting, account information service providers. They will be enabled to have access to banking customer, account information. They will be permitted to analyze customer spending habits, as well as coordinate customers account information from the rest banks into just one in a single deal point. The second ones are payment initiation service providers. Meanwhile, they will be in able to initiate payments on behalf of customers. It includes filled payments and peer-to-peer transfers as well.

There has also been a research in this subject and according to estimates from Accenture bid services could make up around like 60% of online rental payments by 2020. So, in other words, basically to obligates banks to give this third-party provider access to the customer accounts to open API's. That way, they will be allowing third parties to build the financial services on top of banks stop them and infrastructure.

This will definitely open the doors to some very nature tech companies who have had risen and the payments in the state for a long time now. The most obvious one is definitely is Apple and they have made the first step like few years ago already with Apple pay. But we also got Google, Facebook and even Airbnb and they all want to get a little bite from the payments market. This will definitely change the payments value chain. Because when banks customers can use third-party providers, such as social media platforms or messaging apps to be purely straight from their bank accounts then banks might lose many of the customer interactions.

This will happen of course if they don't create equal attractive solutions for their clients. So, yeah, the biggest winners of this new rule are definitely users. Because this ET2 also introduces several measures which will protect customer rights and improve customer services around payments. First of all, it will affect charging for example companies such as airlines or event organizers, will not be allowed to charge an additional card fee on top of the transaction value.

It will also offer better protection around pre-authorization forgot payments. Where the final amount is not known in advance. Such as, who the bookings rentals and so on and so on. That guys, the merchants will only be able to lock funds to limit the growth by the cardholder. That's not all, it will also provide a legacy basis to unconditional refund rates for directed payments. Consumers will be better protected against fraud and the payment incidences. Such as amount they will be obligated to pay for un-authority's payment, that the brought down from 150 -50 Euros. That will still have an exception of fraud committed by the payer of course.

So, yeah there's no doubt that basically to do will offer great opportunities to clients and as well as the businesses. But this new payment and information access tools can be vulnerable to threats. Such as fraud, data breaches, cyberattacks and so on and so on. These regulations therefore establish a security baseline to help mitigate those threats and then the superior customer assets. The main security highlights of this new law are considerations around the regulatory technical standard document.

This includes a strong customer authentication. You see when customer access their payment accounts online, initiate electronic payment transactions or carry out any other actions or remote channels that may imply risk of payment fraud or other abuses. Then so-called strong customer authentication will be required. The minimum requirements are the use of two-factor authentication. This is actually a norm that is already widely adopted by the banking industry.

Simply said, strong customer authentication is a process that is the integrity of the customer by the use of two or even more distinct and independent elements. These are being categorized as knowledge, something known only to the customers such as password or PIN. The second one is possession. Something held by the customer, such as payment card or mobile phone and an inheritance. Something because only the customer is, such as fingerprint or voice recognition or something similar to that.

One of these elements must generate one-time authentication code. So, far we have seen that the most common forms of strong customer authentication have been mobile app, SMS, how to drop tokens or biometrics. Of course, all of before named authentication options have their pluses and minuses. But when taking a decision, we need to keep in mind the regulatory technical standard document. this sets out requirements of how when to apply to a factor or multi-factor authentication in the context of RTS.

This document has now been submitted to the Commission and it will be applicable 18 months after it enter into force. Even though the requirements of 2FA is a new thing to some companies and users as well. It's actually possible to accomplish it while still maintaining a great user experience that even might to improve sales or conversion rates. Because frankly define a language of the regulation reflects a modern understanding of multi-factor authentication and why the final draft of artiest requires to secure and distinct factors.

It also recognizes that these factors can be housed in a single multi-purpose device. By that I mean, mobile phone, tablet, PC and so on and so on. As long as this separate secure execution environments are used and of course trusted platform models are as well. Actually, the main mobile operating systems, Android and iOS most likely meet the requirements of separate execution environments, the other sandboxing techniques. So, organizations can leverage these devices and capabilities to meet the strong customers application requirements easily.

This is actually can be convenient for the users as well, because these devices are already being used RTS. But there are all other requirements as well that we need to keep in mind. This means that, no matter what play you are delivering pingos to customers, to show the payment and the daily information to the users, in every step of transaction. This means that it needs to be showed, then it needs to be generated when it's delivered. In the interface, when the need to be submitted and so on and so on.

Also, the mobile apps need to exchange payment information via secure Channel. They should be equipped with the additional security software that can detect malicious off software itself and prevent them from interfering with the payment transaction. It makes sense but these requirements are kind of poured so we cannot say exactly what techniques should be used. The third one is the requirement to protect the confidential nature of the payment information. This could be actually seen as the need to encrypt the payment information in the SMS message.

But we cannot be 100% sure right now and it would be cleared out after the RTS is being confirmed. They start this new interactive, that we have in your hands right now. The payer’s payment service provider is liable for un-authorized payments. Even if he provides a strong customer authentication in line with their RTS. This should make payment service providers not simply choose the strong customer authentication procedure, that meets the requirements of RTS. But to select procedure that is based on the payment risk that they have in their organization.

If you are talking about the timelines and then the disks of RTS is already. It is currently being translated; it is accepted to be published around 25th of November. In order to become official, there test needs to be published in the Official Journal of the European Union. This should happen in late February 2018. It will go into effect 18 months later, so we expected to happen August 2019. Yeah, so I guess it's a lot of information to take in, but has the dates are getting closer than right now is the right time for business owners to start looking around. Thinking what should be the right solution for their organization.

It would be the smart movement, like the risk user experience cost and so on and on. Then that note I'll give it back to you. If you have any questions then let me know.

Yuriy Mikitchenko: Awesome, thanks Raili. So, when hissing peace of this law and the things that we've been covering today, sheds light on what's already been happening in the industry, right. So, four out of every five hacking-related breach has been caused by weak or stolen credentials, right. Now this law addresses that issue with the requirement for at least two-factor authentications. But it's been happening for years. If you go to the website ‘haveibeenponed.com’, you'll say that nearly 5 billion usernames and passwords have been leaked online. The hackers have access to that to that information.

But now the liability of a hack, due to a weak username and password does not fall on the users. It falls on the organization's, providing an online service or the mobile app right. That's one of the biggest changes coming with these laws. So, regarding GDPR, what does ‘Messente’ do? What can we do regarding them a strong customer authentication? Well, we've invested a lot of time and money to building putting our 2FA toolkit. That has the some of the most secure ways of delivering pin codes for people to login to online services or mobile applications.

So, to start we have our 2FA API, that sends both time-based one-time passwords and SMS pin codes. So, if the user is using our 2FA mobile app called ‘Verigator’, will be using time-based one-time passwords. Which is the most secure way of using two-factor authentication with a mobile application. But if users don't have the application, they fall back to SMS and we can send an SMS pin code as well.

Now PSD2 is a little bit more complex as that need to send payment information when a transaction is made, right. So, users can log in to their account services, using our ‘Verigator’ application. Which is again the time-based one-time password app for users. They can use that to log in but payment information for transaction and the pin code would have to come through SMS, right. Because right now there is no secure way of us sending that information through our ‘Verigator’ app.

But we do have ways to do it through set of solutions to cover both GDPR and PST 2 strong customer authentication requirements. So, Uku and Raili thanks again for representing the information. We do have some questions, that have come through. The first one, I think I'm gonna pass this one off to Uku. It's regarding GDPR. It's, what about consent versus legitimate interest. How much can really be considered legitimate interest? Uku.

Uku Tomikas: Yeah, thanks for that. The first question is definitely one of the hardest ones to actually answer. It's one of the biggest flaws of GDPR is bringing in the legitimate interest sort of way of data processing. But at the same time, not giving a lot of ideas of what it actually constitutes. S, from what I've been able to learn so far, if we for example look at recital 47 for prevention constitutes a legitimate interest. If you look at recital 47 states that, ‘The necessary and proportionate processing for network security constitutes a legitimate interest.’

If we look at recital 50, it names the chairing evidence of possible credit criminal acts to the authorities should be recorded as being in the legitimate interest of peoples. At the same time, recital 47 also says that, ‘The processing of personal data for direct marketing purposes may be regarded as carried out for a legitimate interest.’ Now the part that may be considered of course is again a sort of a fake problem at there. One of the things that has been mentioned was that, behavior advertising and radar procuring, for example, must be pasted on consent.

Because that does not constitute legitimate interest, as it doesn't have and what could be stated as a direct interest to the company that is actually obtaining the data. So, some when were talking about legitimate interest in the sense of direct marketing, the value needs to be shown to directly go through the company that is doing the data processing. In that case, it can be considered as legitimate interest. But ultimately this is more of a hearsay in a sense. Because the topic itself hasn't been debated as much yet.

There are very many different opinions on it and ultimately as with very many other aspects of law and of these legislations. I think that the sort of the ironing out of the kinks of this topic will ultimately come through different legal battles and years of actually implementing this. Going through different auditing systems, going through the countries themselves who ultimately end up really giving the regulation, the definitions that we and the answers that we're looking for now. But at this point that's probably the best answer I can give it.

Yuriy Mikitchenko: Well, awesome thanks. I hope that answer the question. Again, if you guys have more questions or thoughts just please share them in the questions section. If you want to go over audio as well, you can raise your hand in the panel as well and I can go ahead and in it just speak as well. But we do have another question that came in, there's more coming in. This one's regarding our 2FA product set. I think Uku you'll probably have the answer for this one. It's, does using Messenre 2FA product make us compliant with GPR and PSC 2 and if yes, how?

Uku Tomikas: So, if we're taking into consideration, the entire scope with the both documents is no. You need to understand that there are very many different aspects to it, that's discussed before. What ‘Messente’ helps tackle is the part of customer authentication and I national authentication this transaction verification when we're talking about the second payment service directive. As well as the ability to verify consent, verify data access request, deletion request so on and so forth.

For those things, you can use both the 2FA toolkit, the ‘Verigator’ app. Combine those things to have a broad way of both protecting data, as well as protecting customer accounts. You're giving the ability to retrieve the accounts for the customers quickly that they can again access their accounts. When we're talking about documentation that regards to for example consent. When we're talking about implementing a CM system or that security information and event management system.

Then for those we ourselves are compliant as a partner but we do not give compliance in those aspects to people to whom we provide our service too.

Yuriy Mikitchenko: Great. Okay, looks like we have more questions coming in. All right, that Raili or Uku you guys can take this one. Well, the new directives also be used for data and platforms that don't include payments but include personal data and document signing. Then the follow-ups are, the question is. What are the most important changes to that? Let me know if I mean to repeat it, Uku already.

Uku Tomikas: I can take this one. I hope, so when we're talking about PSD 2, I don't think that for when we're signing documents unless they're for example transactional documents. I don't think PSD 2 applies. I may be wrong; this is my opinion from what I've been learning about the two pieces of legislation so far. But GDPR I should apply for those aspects as well. So, you need to have a system in place where you have all necessary procedures for verification set in place. How it will directly affect and what will be the biggest issues is, the fact that when we're talking about for example signing documents and signing documents for different people.

The person sending the document and receiving the document need to be verified for example. The process that the data is sent through needs to be monitored and any breaches need to be dealt with quickly and effectively. As well as have systems in place for both the original signing of the documents, where the signing process itself is protected in a manner. Where it can't be breach or the keys that are used, cannot be for example duplicated or breached in any way. As well as the storage of said documents needs to be done in a safe manner before they are opened by a key, for example that is in use.

I hope that answers the question. If not let me know if there are some specifics, I left out that you're interested in.

Yuriy Mikitchenko: Yeah, I think that the answers the question. But just to generalize it, if there's no payment information or any kind of financial transaction happening. Then I don't, it's sound like PSE 2 really applies but GDPR which is more broad still does and there are authentication requirements under GDPR, right. That makes sense? Oh cool.

Uku Tomikas: Yeah, that makes sense. It isn't explicit to define that you have to have a multi-layered authentication system in place. It says that you have a system, need to have a system in place that is a pursuant to the risks associated. But currently from the research we've done, it's really quite impossible to see any other more effective measures than having on multi-layered system in place. Even if for example, you're using encryption then even those cases having a second layer on top of the encryption will still help you combat things like retrieving access to an account if. For example, a customer key encryption keys are breached, for example.

Yuriy Mikitchenko: So, I got a follow-up question from Moody's. He's got a though question to make sure we're answering this one correctly. Actually, Luke Meliz got some information to show. Luke if you're available to chat with us too, I can unmute your mic and you can give us some information that you know as well, sure. If you're interested? Okay, but maybe later but we have a follow-up question from Aristo, regarding this one Uku. There is a payment, but will be done manually by the user when activity takes place. Does this mean that multi-layered identification or authentication must be implemented?

So, there is a payment which will be done manually by the user. When that with us when that transaction or activity takes place, does this to is multiply factor authentication required?

Uku Tomikas: Okay, that's an interesting question. For me, that the question in this part will be that M is the payment itself when it's made. For example, if it's made through a bank or a sort of a gateway. If it's made by that manner and it isn't directly, it's connected to the signing of the documents. But it's more of a separate procedure from that. Then that particular procedure of making that payment that will need a multi-layer authentication in place. But if we're talking about the signing of the document itself and I'm not certain.

It definitely doesn't hurt to have it in place and under GDPR, it's strongly recommended that you have it in place. But to tell you concretely that, it's a 100% necessity. Then I'd be like, because I am not the 100% sure about that. But we're talking the payment itself, especially for using your gateway or processing provider, they definitely have to have a system in place.

Yuriy Mikitchenko: Yeah exactly. So, if the transactions being made electronically then yes multi-factor authentication will be required. When the user is logging in to use this signing service in the first place, there should be a multi-factor authentication in place as well. Just to make sure that the user is signing the document is the user, the right user the right person. That makes sense, right. So, you an authenticate the user before they actually sign the document. There's, let me know that answers the question or not. But we do have another question. So, we can always come back to you if you have any follow-ups.

This next question is, is there publicly accessible simple language checklist for GDPR compliance available is pretty much a step-by-step checklist or GDPR compliance them? Raili or Uku you guys have both been digging into this. Does this exist yet from the European Union Commission that wrote the laws or from the European Banking Authority for PSC 2? Does that, is there a checklist yet or they can provide that?

Uku Tomikas: That is brightly business plan, I can take this. The really simple straightforward answer is, no. I have not sort of stumbled upon it yet. There are several sites or even like official sites that provide a guide to becoming compliant. But most of it is point sort of like, let say point number 3, take a look at higher currently processing your data, evaluate risk associated and implement necessary measures to combat such risks. Which is pretty much just reading about GDPD. So, RTS for example, does give a certain parameter as it is the regulatory technical standards document, right.

It says certain aspects that are usable. For example, if we're talking about 2FA what things can be put into place in what would be pursuant under PSD2 and ultimately under GDPR as well. But a step-by-step checklist of things that you have to definitely do in order to be compliant. If you move from A to C and have all of those covered, you'll be set, that does not exist. It’s in a very broad sense where you are giving the answers. Because the document itself is purposefully sort of kept broad in order to sort of comply with future changes in technology as well.

If we have new technologies that are going to bring it new ways of data handling. If for example, will be essentially continuously community in with each other through VR for example. There are new ways of doing a processing that needs to be taken into consideration. So, it's left purposefully broad. The ideal GDPR is that, either processing in data processing protection needs to be an ongoing effort all the time, needs to be built into the products from the get-go, maintained, updated. Kept in accordance with the risks as well as evaluating the risks all the time.

Yuriy Mikitchenko: Okay cool. Thanks so cool. Yeah, the regarding legislation coming out of any type of Authority, they try to keep it somewhat vague. Because eventually some of these laws will be challenged in court. But the regulatory technical standards do apply and those are pretty specific. I'll follow that idea to see if we can get you more information around RTS as well. Because that those are pretty specific. Another question, Raili this one's going to be for you. The questions around SMS 2FA. Is sending SMS to client’s phone qualified as strong customer authentication, meaning that the code is generated in banks IT system. The client enters it and law goes in using that code.

Basically, the same way a smart ID or mobile ID here in Estonia, but the device in question is not a smart phone but a regular cell phone. Also, what if the user users a calling card and it's not a contractual client. So, it's one of these virtual networks as well using the cards. So, mean that his or her identity has not been authenticated. So, let's do part question. Is SMS qualified for a strong customer authentication? Second, if they're not using a contractual phone. So, they're using the Comeau ball or a virtual network and identity has not been authenticated to the actual phone or to the SIM card.

Raili Liiva: Yeah, actually a really good question. Because when you are talking about the RTS, this and we are taking this document into consideration when we are thinking about strong customer authentication. Then this actually tells us that, it's mis-verification our or authentication is actually suitable for that. This doesn't mean that, if the client is not, the contractional client or using an SMS or using a sim card only, this doesn't mean that this isn't the good option still. Because there are states that, if the pin is generated and is deliberate, we are secure.

Then this is a good authentication option in that sense. I don't know if that answers the question nor. I understand it right.

Yuriy Mikitchenko: Yeah, I think I'm going to rephrase a little bit. It does answer the question. So, SMS regarding the technical standards, it does qualify for strong customer authentication. Regarding the non-contractual phone, say they're using a virtual network or just they're paying upfront monthly for a sim card. When the user signs up for your account, say that you are a banker or a financial services company of any sort. The user signs up for an account with your company, then they provide a phone number tide of that accounts.

Now when the user signs up and they provide that phone number you can immediately verify that, this is the phone number that they're gonna be using, right. So, that you send them an SMS to them to verify that they're holding this phone, whether it his phone or not. Then this phone number is tied to their accounts moving forward. So, this person would have to maintain possession of this phone to authenticate where they login or provide it, or do a transaction online regardless.

So, even if it is a non-contractual phone it will still work. Hope that answers the question. So, it has to do with the signup process within the mobile service or to the online financial service. It looks we are running out of time. I want to keep you guys too long, but it sounds like we did it to be answered the question, so it's good. But I think that's it. I'm gonna send a follow-up email within the next 24 hours to everybody with some more information, as well as a way you can contact us.

But if you have questions go ahead and email us whether its sales@Messente.com, or you can email Raili, Uku or myself. We can pass through the right people answer questions. Visit Messente.com to check out our API’s, entire ‘Verigator’ app our 2FA application. It's verygator.com to find the links to the Apple App Store or the Google Play Store. And just try out our 2FA process in our application. Get more information on around our 2FA, guys when you check out our website. But more information is to come via email.

So, again thanks for all the questions, really appreciate it. I'm glad we could answer them to the best of our abilities. Thanks for joining our webinar. Watch for more information, when the webinars coming up as well as we want to share as much as we know is with our customers overall. So, thanks again guys. We will talk to you guys next time.