There are two types of industries. We have regulated industries and non-regulated industries. Think about regulated industries like, for example, banks, neobanks, FinTech, digital payments, where there needs to be a really strict paper trail imposed by government regulation. Then, we also have other industries which are so-called non-regulated. It may be a misnomer because they're less regulated rather than non-regulated. But they still need KYB. Why? Because we need to ensure that the people that we're dealing with here are real and reputable. So in both cases, we're trying to avoid criminal action, we're trying to avoid fraud, and we're also trying to avoid being scammed ourselves as businesses. Samsub offers important KYB solutions for all types of industries. It's important to make sure that we are compliant legally and within regulations for anti-money laundering and combating finance of terrorism. We also encourage customer due diligence and Enhanced due diligence to make sure that we're working with reputable companies.

What type of solutions does SumSup offer in terms of KYB? So we have two solutions. We have what we call AKYB and Full KYB. Each of these solutions covers the modules that you can see in the centre:corporate registry check, corporate AML, etc. What is the difference? AutoKYB is where we as a platform, collect the information and we run preliminary checks against our databases. With full KYB, there is the manual input of our Sumsub team. So the difference here is that autoKYB is automatic searches, and it's a much faster solution. In a very, very, very simplified way, we collect the information, we run preliminary checks. Whereas in Full KYB we collect the information and we do in-depth manual checks of the data.

This is your Sumsub dashboard. It should look similar, maybe not the same. Remember, mine is a demonstration dashboard, so it has full functionality. Your dashboard has been configured to your needs. Just a quick reminder of what we're seeing: Profile, Notifications - here we send mass notifications when we have important product updates. Here we have our Help section. You can go into all our articles, and you can also start a chat with our support team. Here you can switch from Production to Sandbox mode, we recommend the use of Sandbox mode when you are testing levels and workflows to make sure everything is going fine. Just a quick side note, if you are able to, please log into your dashboard in a separate tab, so you can follow the steps that I'm doing. On the left-hand side, we've got our super toolbar. Here are all the sections available within the platform, which you can collapse and just have a better view of the high-level data of the people or companies being verified within your platform.

Now, once you create a level, there are different ways of sharing that with your companies that you wish to verify. One of the easiest ways to do that would be by sharing a link. So, let's say we're going to share our iTest_KYB, the level that we created in the previous video. Here you can see the steps within the level. And what I want to do is to share it. You can click this little button, but we're going to go within the level itself, just to have a little overview of what the link, of what the level consists of. And over here we have this button called Verification links. Now, we offer two types of links. We offer the UniLinks and we offer Permalinks. Let's start with Unilinks. UniLink is a link, one link, the same link for the level that you can share with multiple parties. The difference is that once that party starts getting verified, they will need to input their email address. This is different to Permalinks which are created per user. So you would choose the language, you would incorporate an external user ID based on your databases, and you can also choose the validity of the link. You can make the link valid for 2 days, a week, a month. We don't recommend that it's an extended period of time, because the longer the link is valid, the less secure it potentially is. You can also generate multiple links, but again, the difference is just how the user would begin the verification process. They won't need to input the email address because that data is already in the system. There are other integration options, but these are potentially the fastest way to get the verification link to your applicants.

We're back in the main page of our Dashboard, and now we want to look at people who have been getting verified. We're going to go into Applicants, and this time, since it's a KYB session, we're going to be looking at Companies. What can you see when you go into the Applicant's page? We have a search bar, you can use anything you want to search for. And then we also have a number of pre-populated filters that you can also add. Let's imagine I want to look at only "Documents requested" applicants. This means people who have begun the process but not completed it. I have 11 applicants here. If I want to, I can also download a list of applicants. You can also change permission that not everyone is able to download a list of applicants. Then I can reset filters, so basically go back to the whole list of applicants, and then I can see a very, very high level data about the applicants and their status and so on. So for example, if we were to look at our first applicant, Barclays, here we have the name, the ID, the country, the steps that they have gone through, the status that they have been assigned, when they started, when they were reviewed, and any tags.

The statuses there looks pretty important. Can you maybe give me a bit more information about what they are? - Yes, of course, statuses are very important, they help us identify where an applicant is in the verification process, and here's a summary of the available statuses. So as you saw on my screen were a couple of "Documents requested" users, this is when an applicant begins the verification process, but for some reason does not finish it or has not yet uploaded the documents. As soon as they do that, the status is shifted to "Pending". So as soon as they upload all the information required, their status is shifted to "Pending", and that is where the applicant starts getting processed. If we require information from an external service, and that is taking time, we the status is changed to "Awaiting service". If for some reason manual review is required by your company, the status will change to "Requires action". And there, you as our client, would need to take a decision on the applicant. "Awaiting user", this status only appears in KYB. Sometimes, in KYB verification we need to also verify people associated with the business, and that status is assigned when we are waiting for that person to begin or complete the verification process. Now, the last 3 statuses. We have "Resubmission requested". This is when a client does submit all the documents, goes through verification, however, minor issues have been found with the documents, for example, expiry dates, name mismatches, and so on. So verification can't be finalised, and we give them the option to resubmit documentation to go through verification. Then we have our two "final" statuses. Within "Rejected", we have major issues with the applicant. They are not allowed, so to speak, to resubmit documentation unless there's manual intervention from you as our client. Here we're talking about serious issues, forgery, fraud, so on. It is called "final" because we assign this status. However, at the end of the day, the client has the final decision: if you want to change the status, you can do that. =And then we have the one that we're looking for, which is "Approved". The applicant has been verified. There's no further action required from us, from you, or from the applicant, and they can continue using your products as needed. - Do these statuses tell us the difference between an applicant that's in the process of completing the check versus a final result? - Exactly, so we can look at it this way. If we think about "Documents requested", this our initial, starting status. Then we have our intermediate statuses, and then we have our final "Rejected" and "Approved". Those are our final statuses, so to speak. The other ones show us where they are, so if they're pending, if they're being processed, if we're waiting for an outside intervention, the statuses show us exactly where an applicant is within the verification process.

I think now we can actually look at an applicant, and we can get more information about the applicant. So let's look at this one over here. This is what we see when we click into an applicant. We can see their name, the status. We can see the Samsub ID. This ID is assigned to all applicants, whether they have finished verification or not. I'm going to show you that again quickly, as you can see, "Documents requested". They have been assigned an ID number. Anyone who begins the process assigned the number. There's the external ID, tags... In this case, we have a tag. And now on the left-hand side, we've got our toolbar, and this shows us a summary of the verification flow. We have the level that the applicant has gone through, the steps, and that each of the steps has been approved. Bear in mind that if not all of the steps are approved, the applicant cannot be approved. What's really useful about this tool is that you can collapse it and you can see the steps and that they were approved. But also, if you want to check, for example, the AML screening, you don't need to scroll down, you can just click AML and it takes you there. On the main page, what you can see is the following. You can see the events, all the events that the entity has gone through from the beginning of verification until a final status has been assigned. Internal notes are really useful if various people within a team are dealing with data, and over here we have something which is called risk labels.

Why are there risk labels, but the applicant is still approved? - That's a really interesting question. So a risk label is something which the system assigns to an applicant during the verification process based on what is found during the research. So over here we see: one label is that the applicant is using a VPN and that some details are missing from the applicant. As you can see, the labels have been assigned. You've correctly seen that the status is approved. - Yeah, so yeah, does that mean that if there's a risk label, we have to reject it? Or we shouldn't? What's the story? - So the risk labels use is twofold. First of all, it is Samsub's way of giving you more context about the client. Maybe for your company that the applicant is using a VPN is not an issue, but we like to give that context for you to be able to take a more informed decision at the end of the day. On the other hand, a really useful use of labels is within the workflows. Workflows are what you can create to automate work for you, and for example, if you want to flag all users with VPN usage, you can use that as part of the workflow and it will trigger an action based on the label that has been assigned to a client. - I see. It makes sense. It's, it's kind of secondary to the status. The status is what, you know, status the applicant is, whereas the risk labels are just additional context. - Exactly, exactly.

Over here we have applicant information. we recommend that you add the email because, once the email is on file, you can send messages to the applicants. You can add documents over here as you can see. - But, won't the documents come through the user journey? Why would I need to manually upload documents on a KYB? - That's a really important question as well. So, documents are part of the verification, data that applicants need to provide. However, as you know, sometimes documents go out of date, they expire, sometimes names change, etc. So rather than having our applicant go through the verification process from scratch, if by some reason your team does get hold of this document, you can upload it on their behalf. So what you would do is you would add the document and then you would click on request check and the verification starts again and we check that newly added document.

Here we can scroll down and we've got our company structure. Here we have the company and the UBO in this case. However, this is the provided data. But we also use registry data and as you can see through our searches we found the whole company structure of Cervezas Mahou. - Yep, it's really useful. - It's a very, very thorough tool, that we provide. And again, here we have Extracted company data and Provided company data. So remember when we were creating the level, we enabled company search and prefill, and that's where we are getting all of this extracted company data. So what we do is the applicant provides data and in our searches, we start populating fields that we find the information on within our searches.

Now we're going to look at an applicant who has been assigned the "Rejected" status. So again, as we can see, we have the name, the status, and we also have the summary, it looks like we have a different view over here. We have the final rejection, we see the reason why, and we can also view the message that the applicant has received. - Can we change those messages, by the way, that the applicant receives? - Yes. As you can see, we have reasons why rejections can be assigned. We have blue reasons and we have red reasons. Here we can see that reasons "High risk profile" and "PEP" have been assigned. Red reasons mean it's a final "rejection", whereas blue means automatically "Resubmission requested" will be assigned as a status. However, if you scroll down, you can see a message for the applicant. You can remove that and you can type in the message that you want. On the other hand, we have internal note. This doesn't change. And as a reminder, we recommend you do not share the internal reasons why an applicant has been rejected, we recommend you only edit the message for the applicant.