What Users See in a KYC Verification

Full transcript of What Your Users Actually See in a KYC Verification (Full Walkthrough) - Didit Academy video 2 of 10, 14:36. Watch on YouTube. Each paragraph links to the exact moment in the video.

​

What this video covers

00:03 When you send a customer off to verify with Didit, what do they actually see? Well, that’s what this video is about. We’re going to walk through the whole flow from their side. The exact screens a real person taps through after they click your link. a flow you fully brand in their own language on whatever device they’ve got with a stack of invisible checks doing the heavy lifting and the real result landing in your system the moment it’s made and the best way to get a feel for it is to run one yourself. So head over to didit.me you can sign up for free and verify on your own phone in

​

Opening the flow yourself

00:38 a couple of minutes. Okay, so the easiest way for you to see exactly what your users go through is to open the flow yourself. So that’s what we’re going to do. Uh we’re going to head over to one of our workflows here. We’re going to copy the link and we’re going to put it in the browser. So let’s just take this basic KYC workflow. We’re going to copy this link and we’re going to pop it in here. So right here is the

​

The first screen your user sees

00:58 very first thing that your user sees after they tap one of your links. So the first thing to notice that well this is a demo for it. So we do have the Didit branding on here, but you can fully customize this. This list here is every step this particular user will go through. So we’ve got ID verification, face verification, and additional documents. So this list is not hardcoded. The workflow that this session is attached to is actually going to decide which steps show up and in what order. So this flow just renders

​

Branding, and why it drives completion

01:28 whatever is inside of that workflow when you turn it on. So the logo and the styling are yours, too. So to the user, this still feels like your product. That’s pretty important because how much it feels like you and your brand is the single biggest lever on how many people actually finish this verification flow. So there is one small mark down here secured by Didit and even that’s removable. Everything above is yours to configure. Did just the engine that’s running underneath. So what your user sees is exactly the workflow that you set up wrapped in your brand. So here’s

​

The checks that never show a screen

02:00 something that surprises most people. Not every check you see here has a screen. The only steps that show up are the ones that genuinely need the user to do something. So document, face, phone, email, and while they’re working through those checks, a whole set of other checks is running server side with nobody touching anything. So device and IP intelligence, AML screening, ongoing AML monitoring, database validation, these are all happening in the background. The user never sees a step from any of them and you still get every result back in your dashboard. And that’s how the flow stays super short while still doing a ton of work. Some of did its strongest checks at zero friction because they never face the user. So if you go back and look into one of these workflows, we could see here that we’ve got all these background checks. We got database validation. Uh we’ve got email verification, phone verification, AML screening, IP and risk analysis. So these are not public facing. These are all the checks that

​

Customization: colours, logo, email, domain

03:00 you can add into a workflow. So let’s take a look at the customization tab. This is where you’re going to be able to add in your branding, your colors, your own email address, your own domain, all of this stuff. As you can see here, we can change the name of the app. We can show the welcome page or turn it off. We could show the progress bar or turn it off. We’ve got the branding tab where we can add in all of these colors. Can add in the logo, the favicon, and change the typography. We can add a custom email. 03:25 So, if you just pop in a name here, we can put in a an email address and we can continue to verification. This is going to give us the that’s not worked out. But if we put in an actual working domain and we click continue to verification, that’s going to give us the DNS records uh that we can add and we can set up a custom email address. And this email is where the notifications are going to get sent from and all the updates about the verification status. For the domain, we can also add a custom domain. So, we had a subdomain for example. And again, if you add in your subdomain here, it will give you the the records that you need to update on your domain provider. So you see this globe up here. The

​

54 languages, auto-detected

04:04 interface ships in 54 different languages and that includes left to right scripts like Arabic. And by default, this flow just auto detects whatever language the browser is set to and falls back to English if it doesn’t support that particular language. But the user can open this searchable list and switch into any language at any time and have every instruction follow their choice from there. And if you already know someone’s language ahead of time, maybe on your own database, you can set this language when you create their session. So it opens in the right language without relying on the browser at all. So the flow meets the user in their own language automatically with 54 to choose from. So, if we take a look at

​

Mobile vs desktop, and the QR handoff

04:49 this preview, you see most people end up verifying on their phone. And that kind of makes sense, right? The camera makes capturing a document and a selfie super easy. Someone would just point their phone at this QR code and they’ll be able to continue the verification process on their phone. When someone lands on this page on desktop, you could see here we can actually continue on desktop, but that’s an option. You can force people to just verify through their mobile, but you can absolutely enable desktop and and let them finish right here on the computer instead. But if you do, just know that the livveness check gets forced to passive on desktop because the active version doesn’t really play nicely with computer webcams. And what I mean by active versus passive is where you have to

​

The hosted flow vs building your own screens

05:34 blink on the camera. That’s an active livveness check. Whereas passive is just a a photo. So the simplest path to get started is the hosted flow. You see when I hit this copy link and I open it up in my my browser. You could send the user a link and Didit handles all the hard parts for you. So the camera permissions, the document capture, the livveness, every fiddly device quirk. So you can drop this into your app through the SDK, an iframe, a redirect, or a pop-up. And if you’d rather build your own screens from scratch, you totally can. But then you’re on the hook for all of that. We get into the integration side properly in another video, but for now just know that the link that you’re sending that you’re getting from this workflow is the hosted flow and it’s tuned to get people through to the end.

​

Detecting the issuing country

06:20 Okay, so back into the flow. When the document step needs to know which country the ID is from, most of the time the flows already figured that out. It geoloccates the user from their IP the moment the page loads and pre-selects the issuing country. And here you can see that it’s worked out. And if your workflow only allows one country anyway, that’s just going to get selected automatically and they’re never going to see this picker. Uh this example here is a KYC flow, but this is going to be exactly the same for KYB or any other workflow that you build. The engine just runs whatever steps that are configured inside of your workflow. So next, as you can see here on this preview, the user

​

Choosing a document type

07:00 is going to pick which government document they’re going to show. So didit recognizes seven named types. There’s passport, identity card, residence permit, driver’s license, health insurance card, tax card, and social security card. But this list is filtered down to only the ones that are actually valid for the country we just detected. So the user can’t pick something Didit can’t read. And again, if your workflow only allows for a single document type, this whole screen gets skipped and they

​

Capturing the document

07:26 go straight to the capture page. So if we continue, we go to the capture page. So, as you can see here in this preview, I am on my desktop and so I can upload a file or I can take a photo. So, forcing a live capture instead. It’s going to drive guided real-time photo with no uploads allowed. And that’s your strongest setting against tampered or recycled images. So, on the upload side, the accepted formats are your classics, JPEGs, PGs, PDFs, and a few other file types, all under 10 megabytes. And if it’s a PDF and it’s password protected, it’ll prompt for the password. So we can either upload or we can force a live capture and that’s all configurable inside of your workflow settings. So as you can see here in this preview as they line up the document ondevice cues are checking the lighting and the sharpness and it captures automatically the moment the shot is good enough so the analysis can start right away. And it’s not just reading the text off the card. Didit is running authenticity and tamper checks, a document livveness check that catches things like a photo of a screen or a printed copy. It’s also doing security features and checking the MRZ validation across more than 130 document languages. 08:37 And the thing that really sets this apart is it’s all happening in real time. So the user finds out instantly if a document didn’t work and you get the exact same data at the same moment. So everybody wins on speed. So for the

​

The liveness selfie

08:50 livveness check, they can take a selfie. The user just centers their face in the oval that will appear on the screen from this step that you can see here. And behind that simple screen, there’s a livveness check proving a real present human is actually in front of the camera. And that’s also what lets Didit match the face against the document they just submitted. So you could choose which livveness method runs here. And you can set it per workflow node, which we are going to get into in other

​

Passive, 3D flash and 3D action

09:17 videos. And there are three different settings. We’ve got passive where the user does nothing. We’ve got 3D flash where colored lights build a depth map and still asks the user to do nothing and a 3D action which adds the lights plus a randomized little action like blinking or turn the head. So it’s one selfie step with three livveness strengths that you get to pick from. So

​

The liveness video and scores

09:41 let’s take a look at what that livveness step gives you. It records a short video of the person and scores it. So, if we go over to the user verifications and maybe we scroll down and take a look at one of the users here, we can look into their profile. And don’t worry, we’re going to get into everything that’s inside of this verification check in another video. But just to show you what the livveness check actually does and what it gives you inside of your profile is a short video that you can see here. 10:08 So, we could play the video. And yes, this is just a video for demo purposes, but this is what will actually show up for each of your users in the verification step. We have a livveness score here in a percentage. I’m going to get into that in another video. So each of the methods, the passive or the active, spits out a livveness score from one to 100. And it runs presentation attack and deep fake detection on top. 10:30 So the video gets saved right alongside the score. And you can come back and replay the video and read every score right here in the verification check. and also in the user’s profile. So you walk away with the selfie video plus the livveness and the deep fake scores

​

What happens when a step fails

10:45 replayable whenever you need them. So what happens when a step fails? The user doesn’t hit a dead end. They get a specific guided retry. And in the settings inside of your workflows, you can set the maximum number of retries, the retry window. Um but we’re going to get into more of the settings and how these workflows work in another video. But when they do see a retry message, it’s going to be precise. something like the document expired or retake this in a stronger light, not some vague generic error. So they know exactly what to fix and how many attempts that they get is configurable as I’ve just shown you here in the workflow. By default, the flow just lets them keep trying until they get through because the whole goal is to finish them, not to lock them out. So attempts are tunable and the default is

​

The approved screen

11:30 built so the user can always reach the end. So when every required check passes, the user lands here. So, a green check and a plain language. You’ve been verified. It tells them there’s nothing more that they need to do and they can head back to your app. And here’s the part that they don’t see. Your app has already gotten the verdict in real time before they even tap away. So, approved is this green reassuring end screen and

​

The under-review screen

11:54 your back end already has the results. So, sometimes an automated check raises a warning rather than a clean pass or fail. When this happens, the user is going to end up seeing an orange clock instead of this green check mark. With the text underneath, your submission is under review. So on your side, the verification is going to come in to here under review. And it’s going to be up to you, somebody on your team, to either pass them, to approve their application, to decline, to ask them to resubmit with more information. And the cool thing is that user is going to get an email the moment the status changes on their

​

The declined screen

12:30 verification request. So if a check genuinely fails, they’re going to get a clear declined state. So they’re going to get a red mark with the words, “We couldn’t verify your information at this time,” which explains the outcome without giving away any of your fraud logic. So what happens next is entirely up to your workflow. You can let them resubmit within whatever attempt budget that you set or route them into a support flow inside of your own app. So declined is a clear non-technical end

​

Redirect vs webhook: which one to trust

12:58 screen and you decide whether that means resubmit or support. So two things happen at the very end of this workflow and it’s worth knowing which one to trust. Right? So first the user’s browser bounces back to your app. So they land right back where they started but that part is really just a handoff for them. The thing you actually rely on is the result that your server gets at the same moment sent straight to your back end the instant the decision is made and that’s the version that you build your logic on. Never what’s just sitting in the browser. The nuts and bolts of wiring that up are a whole video on its own. And so we’ll save that for later. But the takeaway here is simple. The user returns to your app and your system already has the real trusted

​

Finding the session in your dashboard

13:41 results waiting. Every verification is going to show up in the user verifications tab. We got the filters here. We could see approved, in review, approved, declined, and depending on the outcome of the verification and the workflow that they’ve gone through, then that status is going to update accordingly. Now, the ones that are in review are obviously the ones that you’re going to need to pay most attention to. So, we can filter that out and just have all these in here for human review. And with each of these verification checks, we can click in and we can see every piece of evidence behind the results. And this value down here, the vendor data, this is the ID that your own system sent across when it created the session. It’s your stable reference for that person. 14:25 And Didit groups every session that shares the same vendor data ID under one profile?