Hey, good morning, it's Alistair Anderson. Well, I'm gonna talk to you about today. Well, I'm going to, I'm going to tell you how to do two things are demonstrate two things. I'll talk you through two things. The first thing I'll talk about is how you develop ADA secure data sharing service. And the second thing I'll demonstrate is the one problem that chat GBT can't solve the Glasgow accent. It's impossible for artificial intelligence to understand. So if you guys do, that's great. If you don't, put up your hand and ask a question, and I'll go into BB, C English for you. Okay, so what's the secure data sharing service? Well, first of all, why would you need one? And really it's, it's a challenge of the, the sort of world that we're living in.
I think up until OpenAI released GPT 3.5, the demand for data was pretty high. Since the last 12 months, the demand for data has been off the scale, absolutely off the scale. And when you realize that they train those models and, and the entire internet, is that better? When you realize they train these models and the entire internet, you realize that getting them more information than the entire internet might be a bit of a challenge. At the same time, you're seeing a lot of regulations about what is an acceptable use of data. And also there's what I would describe as a sort of data nationalism that's going on, and that people are, people being, governments are starting to deglobalize almost and insist that data be held within certain countries. The data cannot travel, and therefore you have to very careful about what information goes where, what happens when it crosses borders.
And this is especially important when you look at global supply chains and how you run your business, especially if you're in the sort of the virtual, the e-commerce world. So you have this classic sort of squeeze between supply and demand. The demand for information and utilization and being able to use data is, is way higher than it was even just 12 months ago. And it was pretty high then. And at the same time, people are cutting off the supply. So how do you, how do you go about answering these, these challenges? And this is the point of the presentation when I realized it's someone else's slides and I didn't realize there was animation on it. Oh, click, click, click, click, click, right, there we go. So what you'll notice here is I've got two techniques for protecting information. There's another thing you'll notice is that encryption is not there.
So encryption is as useless as it is useful because as soon as you encrypt data in order to use it, you have to decrypt it, which gives you a problem. That information is in the clear. The other thing I'll point out, apart from the fact we've used American spellings, which also shows that it's not mass light an an anonymization, is that these are legal terms. Because when you go to use information, you're gonna have to clear it with the lawyers, with compliance, with the regulators, with your authorities, okay? So it's a good for technical people like us to get in the mindset of using the language of the people that are going to give permission for what we do. So really to our mind, the when you protect information, you have to keep it useful because if you encrypt it is by definition quite useless.
It's very protected, but it's quite useless. And therefore you have two techniques in order to protect data. One is pseudo anonymization and one is full anonymization. The difference is, is, well, it's up there in the board, but the way I explain it is pseudo anonymization, you can get back to the original data. So you can see the first name and last name of the information you've protected. So somewhat like encryption, except you don't have to unprotect in order to use it. Anonymization is different. It's a one-way process. I think we've all used very, very, sort of easy versions of it when we're trying to generate our test data sets for non-production environments. But nonetheless, this, when you're looking at how do we grow data sets, how do we share data? Anonymization is a very, very valid technique. What I'm gonna focus today on is, is the pseudo anonymization part.
And just give a demonstration, not an actual demonstration. There's no computer here for me to use, thank God, but a demonstration of what our customers use this for. But before I go onto that, I'll explain, you know what I mean by pseudo anonymization and how we approach this problem. And again, here we have animation I didn't know about. Okay, so it's really simple technique actually, but it's really hard to do. The first thing is you, you look at all the sensitive data. So not all data is equal. So if you look at your average database or file store, wherever you have your information about your, your customers or your processes, there's loads of data bits that actually you don't care about. You know, database flag fields, you know, markers to say what their preferences are on a certain screen. Those are very different pieces of information where we, we examine that against first name, last name, your social security number, your date of birth, even your gender actually is quite, it's quite a useful piece of information for the bad guys.
So we would allow you to tokenize that data. Now what does that mean? It means you take the information and you replace it with a token, which is another piece of information, but it's a two-way scrub, but it retains the, the character in terms of length and also the type, but also maintains referential integrity. So that's a database term to say that you can still run your business intelligence reports, your analytical models, your AI processes on the data without ever having given those processes, the actual sensitive data itself. Why is that hard to do? Because I said this was easy to explain, hard to do because the first thing you have to know is where is my sensitive data? That is a bit of a challenge when, you know, I'm sure some of us are looking at databases that were built 20 years ago, maybe even 30 years ago, and the people that built them are retired or dead or even worse.
But nonetheless, you've gotta find that data, then you protect it and then it changes the way that you deal with data. Your data in your enterprise is by default, always protected, and you only unprotect are based on a permission and a rationale and a justification to use that data. And that takes me back to the legal definitions. What data are you going to access for what purpose and why should you have access to that data? And it allows you to build up different views, people in different job roles, people with different permissions can see different views of the data. I'll show that in a minute. But really viewing data in the clear becomes the exception. And if you think about that, that really radically reduces the risk that you're carrying within your systems, within your processes, within your interfaces.
Okay, so what about this slide up? 'cause it's easier for me to talk about pictures. So when you've done that, when you have put your sensitive data protection in place, it then gives you ability to map those unprotect. Remember, we protect by default and then unprotect on exception to the need to see the data. So when you're looking at a data, data in a database, a database administrator or a systems administrator, they never need to see that information. So it's always protected when you're looking at someone who's doing maybe some data science, so some modeling analytics, AI type stuff. They have a need to see in this case, you know, date of birth, sorry, just the gender and the location, but the, the date of birth and the names are still protected When you're looking at someone. In this case, we've taken medicine, when you're looking at someone who's dealing with patients in a hospital, they need to be able to see everybody.
They need to be able to call your name, they need to know who you are, okay? But they only need to see that one record at a time. But as a data scientist needs to be able to run their models in the entire dataset, all customers. And that's where we run into really big problems in, in utilizing information if we don't protect, okay? So by default, everything is protected by exception. People are able to see the data as they need it, okay? Now what it allows you to do is build up a model of how you deal with your data on a use case by use case basis, I mean, this is at a very high level and I'll like, I'll talk you through some customer examples of how they've implemented it, but really you have a, you know, you always have central functions, whether they be your, your legal department, whether it be your compliance department, people who tell you what you can and can't do with information.
Then you get down to, you know, is this information used inside the company or is it used outside the company? And then when it's used inside or outside the company, where is it used and for what purpose? So you start to go down the sort of the decision tree of can someone see some data and that allows you to implement policies. Now the good news is, is you, you guys are already doing this because this is the same approach we have when we look at authentication identification type models, okay? What we are doing is taking a deeper view and then eliminating that sort of, that exposure of data in the clear. So following the zero trust and trust no one and ask all the time, we are making sure that people are asking the questions. Why do you need to see this data for this purpose?
Okay, now what I'll do, I think it is always relevant to find out, I mean, look, I'm a software vendor. I'm gonna tell you stand up and say this is fabulous, this is the best thing you've ever seen in your life. But what's best to explain is how people actually use this software. Okay? And if you, you buy me a coffee, actually, you don't need to buy me anything. If you get me outside, he'll tell you it is. Okay? So this is a global bank, super big bank, you know, your $2 trillion balance sheet, although you can see this slide was made in America because Switzerland is somewhere beside Benidorm and Korea is in the Pacific Ocean. But nonetheless, this is an example of really where our software does its best, right? So we have a team of two guys, literally two guys in New York who run the centralized control function, but they then allow that service to be consumed.
So they call it DPAs data privacy as a service. They allow that service to be consumed via rest, API globally. Now the enforcement and the controls are then pushed down to the regions. So the biggest success they had was dealing with Switzerland, which is always a problem for, well, it's a problem for most folk, despite the fact our neutral, neutral seems to be they don't do anything, but it allowed them to actually implement data security from the US but make the people in the Swiss private bank, in this case completely the the last line of enforcement. So none of the policies that were applied in Switzerland were accessed by anyone outside Switzerland. So it was quite a rigorous control but also a dynamic implementation. And what it means is it allows you to move data protection back into your development environment. You can, because it's just a rest API, you can embed it into your DevOps processes.
You can have, you know, part of your continual build, your data is protected. So you flag the data, you find that that problem that I talked about before, and then you auto protect as part of the development. And then you can see a global view of who is using the protected data because you can scan your software repositories. We all do that and see what build processes are using the protection and what are not. So it allows, you know, some of the, you know, this is a bank with I think 200, 300,000 people allows the executives at the top who are responsible for that risk to be fully attached to the, the risk that's getting carried at the ground level and view that across the globe. Now, the fact that they can do that in a very rapid pace, because it's not our software that we are implementing for each project, it's our software that's being made available for people to implement. So they've got 40,000 developers that gives guys can all access the same rest API and build it into their code. So it allows them to completely parallelize the rollout of the security. And we've all been through big projects that are centralized and you become a bottleneck. So that bottleneck is removed, but the central security administration and the running of the service is run by just two people, whereas the enforcement is done by all the local regions, which is consistent with their laws and their business processes. Okay?
We change industry here. We do a lot of work in the medical sphere, more in the US than we do in Europe. That's just a, a, a fact of life for the, for the medical industry. This is a, a company that does kidney dialysis. So if you have kidney disease, it's pretty awful thing to have. You have to go and get a dialysis three, four times a week. This company are in the sort of the, the front side of that and that they have clinics where people come in and they get their treatments. So one of the products they have actually is a kidney dialysis holiday service, believe it or not, is you can go on holiday, but you're beside a clinic where you can enjoy the sunshine at the same time, you know, stay alive, which is also a good part of a holiday.
So the challenge they have is they're part of that whole medical world, you know, as we saw in the pandemic, you are expected to be able to share your information really, really quickly. So the, the, you know, the customer success in their world is that they are improving the quality of life of their patients. That they are, you know, working with the, the medical equipment suppliers and the pharmaceutical companies to get to better outcomes of people's health. In order to do that, they want to share their information, but they're, you know, they're spread, they're actually a, a Swedish based company, but they're spread all over the world and therefore they run into all those sort of data movement challenges we've, we talked about. So they are able to sort of protect the information once and then look at what is applicable based on the, the sort of level of trust they have with their partner.
So for internal type processes, they might actually have data in the clear, like we saw with the example with the, the nurse in the hospital where we, when they're working with pharmaceutical companies that will be completely anonymized so they can never get back to the patient, okay? So it gives them the flexibility to use the appropriate protection for the appropriate partner as well. And obviously they can talk about how they're significantly increasing people's quality of life. The next two, last two examples are really come out of the sort of financial world. And that's because there's a lot of processes that banks and insurance companies do that they all have to do, you know, so things like check for, you know, credit checks, check for anti-money laundering, stuff like that. Check for sanction screening. There's obviously no competitive advantage and someone doing this great. If they do it great, fantastic.
The really danger is that, that someone does it really poorly and exposes the whole network to, you know, terrorist financing or the mafiaa cleaning their money. So this is, this is actually a Belgian bank, this is AML stands for anti-money laundering. And this is a service that they've launched. We are used as a debt protection there. And what it allows people to do is to send all the very sensitive financial transaction information to the central service completely pseudo anonymized. These guys can run their models on this as a cloud-based system. These guys can run their models and they're looking for what the, the banking folks call red flags or SARS suspicious activity reports, which is people who could be bad guys, right? And in some countries you actually, as a processor of that information, even if you are the bank, you are not entitled to see who that potential red flag might be.
So air protection allows all those processes to run. You know, I used to work for financial services company in, in Denmark and actually the bank could never see who the red flag was. We had to give it to the police. So you get that ability to have a differential view of the data that goes straight through the organization in some cases where it goes to an external party and only they can see who that is. The last example is similar. This is for a, a global analytics vendor. There's only three of them. So, you know, you take a guess, you might, you get 30% chance of getting one, right? This is about, again, it's a shared function that everybody has to do. What is the risk exposure on commercial loans? You know, I think as we've all seen, offices are a lot emptier than they used to be and therefore people are working out what is the, the potential of a default.
How much money would we lose if this loan goes bad? Stuff like this. This is a service that was always delivered on premise, is now being delivered in the cloud. And again, people can send their data to it. Pseudo anonymized, it goes through the whole processing and then it only becomes re-identified when it comes back to the client. So the processor never actually sees the data. Okay? So really that that sort of, sort of magician's trick that we play has many ucs as you look at, at across your systems, your processes, and even the people that process that data. And that is my crescendo. So thank you for listening and if you've got any questions.
