Build a durable KYC flow with Temporal

Hello and welcome to this video on building a durable KYC process with Temporal. What is KYC? Well it stands for Know Your Customer and it's absolutely integral to the financial services sector. It basically allows financial institutions to understand you are exactly who you claim to be when you apply for something like a bank account or a mortgage or something similar to that. Not just financial services but also things like passport authorities or even new employers may ask you to go through a KYC process. So it lends itself nicely to what Temporal can do. What is Temporal? Well, let's not get ahead of ourselves. Let's jump in and take a look at what we're going to look at in today's video and hopefully that question will be answered in due course. So first up we're going to look at the KYC process we're following today. It's a slightly simplified version of what you'd probably find out there in the real world but in terms of demonstrating concepts it's totally fine. We'll then go through the happy path demo of our solution so we'll exercise the flow by automatically approving somebody for a product, declining them and then also falling into a human in a loop validation process. We'll then look at the individual solution components that make up the solution itself, because that will then set us up nicely for the second part of the demo, which is to start breaking things and getting things to fail as part of our solution, and then seeing how Temporal can come into the mix and actually help you recover from those failures and help you maintain durable state as part of your workflow. And then finally we'll do a code walkthrough of all the temporal concepts that we'll cover in the video. But before we go on to that, let's take a look at our KYC process. So the KYC process begins with a customer or potential customer signing up for a product. We'll then attempt to ID and V them and the result of that will either be an automatic rejection or an automatic approval. In the case where we cannot determine that based on what they've provided to us, they will then fall into a manual human in the loop process where a compliance officer will need to review the cases manually. And in our flow today, there is an escalation flow where if the compliance officer hasn't reviewed each case within 72 hours, they will be escalated. So at this point, start to think about things. like potentially long-running processes, human in the loop, as well as timers counting down SLAs, things like that. And then once the compliance officer gets round to reviewing each case, they will either reject them or approve them, as we have attempted to do with the IDNV check. All right, so that's a very, very simple process. Now let's go on and move through our demo to see this process in action. All right, so let's move on to scenario number one, which is our happy path. So move that off to the side here. And all I'm going to do is create a request for a bank account that I know is going to succeed. It's going to hit the KYC service. It's going to go, yeah, that's all approved. And we can take a look and see what happens. So I just kick that off now. We should see some temporal activity over here. Now, the first thing you can see that's happened in this view is a temporal workflow has been created and it's in fact completed. It was super fast. So if you just drill into that, we can see what's happened here. There are a number of steps within our workflow. Now, this workflow is basically modeling the KYC process. You can see here that we actually have two activities that have executed. The first one here is verify identity, which is a call to the ID and V service. If you look at the completed step, you'll see the result back from the API was approved. So nice and simple, nice and happy. And then that moves us on to the second activity, which is to basically activate our customer in our system. In terms of the compliance console, nothing's happening there because there's nothing for the compliance officer to do. So that's our happy path. temporal concepts to think about are things like workflows that's basically modeling our business process and then within workflows we have things like activities which are our calls to other services be the external or internal services all right so that let's move on to our next scenario So our second scenario is for a manual review to be required of a compliance officer. So let's move that off to the side. And I'm just going to generate another request for a bank account. This time, the ID&B service is going to be a bit more ambiguous in its determination and require a manual review. So I'll send that over now. You'll see that we have a second temporal workflow. This time it's continuing to run. Okay, so start to think about ideas of long running processes. Now, because we are basically inviting a human into the loop, that of course could extend the duration of our workflow from days to potentially weeks or months or even longer than that. If we drill in and look at what happened, you'll see we had the same activity. fire, verify identity. If we come in and take a look at the result from the IDNV service, though, you can see that it says that it needs a review. Okay, so it couldn't determine what actually has to happen with this customer. We then have a new activity, record waiting for review. This is just a little update to our own database just to provide extra information to our compliance console. It's not at all used by Temporal to maintain state or anything like that. It's really just a read model for our application. that completed and then we have a third activity executes notify compliance officer and if we bring over slack onto the screen we should see that we have indeed received a notification in slack for a new ticket and we also as you can see here received notification in our compliance console as well then the next thing that happened was the timer started so this is looking to talk about SLAs and things like that so a durable timer has kicked off where we are waiting for 72 hours and if after 72 hours this has not been actioned then escalations will start to happen we'll cover that in the next scenario though for now what we will do is we'll just open up our case and we will approve it now just before that let's just add a little marker in here this is just saying this is visual just to help you understand what's going on so waiting for lines check we just put that in here you can see that when we then approve the ticket the subsequent activities that run so let's just approve it and we'll see the rest of the workflow execute so what you'll see we received first there was a signal saying that review has been completed so long running workflow timers signals now the timer was then cancelled because we've obviously executed what we needed to do i.e review the case and then our last activity has run and we've seen this one before which is the activate customer activity because we approved this case so quite a few temporal concepts have come into play here we'll deep dive them a bit later but should start to get you thinking about what is going on with temporal next up we'll look at the escalation process so scenario three is escalation it's fairly similar to the last workflow that we looked at this time the escalation occurs and so i'm going to change the 72 hour sla to something a little quicker which in this case is going to be 30 seconds so if i fire that in we'll see a workflow again it's created all the same steps as before this timer timer is just for 30 seconds so if i just have a little waiting marker here just so we can kind of visually see what happens once the timer elapses you'll see the timer fires and we fire off and escalate activity and if i bring slack onto the screen here i might be too slow manage just to make it the escalation should fire and we'll see that come in to slack indeed you can see that happened there so let's action this we open up and we just decline it let me just move this down here let's add another marker in we'll just say decline about to decline add marker and we'll decline it You'll see that again, we got a signal back to our workflow. The third timer, which was the timer that was executing at that point in time, is canceled. And then we just simply record the fact that we declined this particular customer. Okay, so that's all our happy paths. I mean, not very happy for this particular person. They didn't get their bank account, but that's our happy workflow done. Now we're going to move on to our scenarios where we start to break things in our system and see how Temporal helps us deal with that. So just before we go on and actually look at the failure scenarios, it's probably a good time to sidestep and look at the solution components that make up the system we've been working with today because we're going to fail some of those individual components. And if we don't have a clear view on what they are, then it might be a little confusing. So at the heart of everything lies the temporal server. This is something you can host yourself or you can use temporal cloud offering. This is not something that you would write yourself though. This is fundamentally the temporal product and in the context of today's conversation I'm going to say it's responsible for maintaining the state of our application in terms of what we've written ourselves as developers we have our web front end which talks to an API and this is the API I used to create work so fundamentally the API you can think of that as a temporal client requesting work of the server Now, in terms of the work actually running, it's not the server that executes the work. That is done by a worker process that you would define. And the worker takes work requests from the temporal server. So the worker runs the workflow. The temporal server maintains the state of the workflow. It basically knows everything that's going on. It is the brain. the worker is the muscle now in terms of the anatomy of our code project we'll look at that later but our workflow is a separate code project and that's where you define your happy path business flows as a workflow and you also define your activities which are calls to the various external systems that we are reliant upon okay and the worker uses that of course in terms of the external systems we're calling we have our mock id and v server and we have slack And then finally, we have our database. That's our application database that our API uses to feed data back to the web UI. It is not anything to do with the temporal server directly. It's not anything to do with how state is maintained in our application. It's simply there to provide a read model to our web front end. The worker will update it with some statuses and things like that. But again, the status is all maintained by the temporal server. And in fact, it has its own database, which I've just... put there as a dotted line what that means is we can kill our database which we will do in the next scenario and we'll see what happens and then the other failure scenario is to kill the worker as well and this is going to be interesting when we look at what happens to the escalation timer when the worker dies so hopefully that made sense now we're going to go on and start breaking things so let's look at our first failure scenario which is to take down our database that the compliance console uses and you've seen activities occur in the previous runs of our workflows where we've been writing to that database so we can feed our compliance console so we're going to take down the database and we'll see how temporal handles that database failure so let's move this off to the side and i've just cleared down the previous workflow runs just to keep things looking a bit clean and tidy and what i'm going to do is just send in another request for a bank account it's a long-running process for waiting for review so if we come in and have a look at the steps you can see all these things that you've seen before and we've got a 72 hour timer. So as a compliance officer, I might come in here to have a look at this and just as I'm about to approve it, we have a database failure. So I'm just going to stop the database on the other screen here. So our database is down now. So I'm going to approve this and we'll see what happens. So you can see that we've got a signal as before, a review is completed, timer. it's cancelled and we're now running the activate customer activity and you can see we have it has a pending activity and what you can see here is it's just retrying to contact our database okay so this is all under temporal control our workflow is still running the temporal server is still maintaining the state of our workflow our worker is still running but we cannot contact our database Now, you could, of course, depending on the retry policy, specify a finite number of attempts. Because this is our internal system and we're fairly confident that we can probably get it back up and running fairly quickly, this particular retry policy is just trying again and again. So what we'll do now is we will spin our database back up and the next retry should be successful and our workflow will just keep going from where it left off before. And indeed, you can see that here. Our activity started. It's now completed successfully. If you just open that up, indeed it has. And our workflow has successfully completed. And if you look in the audit log, this actually shows you what happened. Our customer that requested the bank account is now active in the system. So we have this durable, this concept of a durable workflow, even in light of things failing. Okay. So again, we're going to deep dive this a bit later. that's just showing you one aspect of temporal retry policies next failure scenario we're going to take down the worker and the worker is responsible for actually executing the workflow okay so we'll do that next so in this next scenario we're going to take down the worker process that's responsible for executing a workflow and in particular we're going to be interested to see what happens to the sla timer when that worker dies so let's move this off to the side and i'm going to fire in a request for an account that i know is going to get escalated so i'll fire that over now we come in here you'll see all these activities that we saw before i'll just put another little marker saying uh kill the worker add the marker and then let's do that let's kill the worker process so kill that so our worker is down our timer was counting down from 30 seconds to escalate We don't have a worker process now to run the workflow. What happens to that timer? And if we wait long enough, we should see the timer still fires and it's the temporal server that's maintaining the state of that timer. So irrespective of whether we have any running workers, the timer, in fact, the overall state of our entire workflow is still maintained by the server. We've taken down our worker. You could potentially have multiple workers waiting in the wings to take over the work. In this case, we're just going to restart a new worker. And what will happen then is it will go to the temporal server, replay all the events that you can see on screen here so it doesn't execute those again. So, for example, when we restart the worker, it's not going to try and verify the customer again. It's not going to notify the compliance officer again. It's just going to pick up where it left off. And at this point in time, the workflow is still running, as you can see, but it's kind of in this state where we are waiting for a worker. All right, so let's run this back up. It goes to the temporal server, replays the events, and it sees that, oh, the timer has elapsed. I need to fire an escalate activity to notify the compliance officer or to escalate it to the compliance officer. And the workflow just keeps going. As before, we've not done anything as a compliance officer, so we have our second timer kickoff. So the point here is, irrespective of our worker dying, state is still maintained by the server, and it gives us this lovely durability. All right, so let's just finish this off. We'll approve that, and you've seen all this before, and our workflow goes to successful completion. So how does this all work? In the next sections, we will look beneath the covers and see how Temporal does all of this. All right, we've come to that point now where it's time to walk through some code and delve into some of the Temporal concepts that you've encountered in a bit more detail. So move that off to the side. And as I've already mentioned, this is a .NET. solution comprised of multiple projects. In terms of the projects that I'm going to look at today, I'm only going to look at three of these. And that's the first one, the API one, which is kind of a temporal client, if you like. That's the API that I fired requests into that kicked off the workflow. We'll then look at the application project, which contains our workflows and activities. This is arguably the one that we will spend most time with. And then finally, we'll take a quick look at the worker process. Now the code is available on GitHub. I put the link to the repository in the description below. So please take a look at that. So perhaps we take a look at the API first. In terms of the application itself, it's actually very, very simple. We're just doing some DB context setup. So that's a connection to a database, adding a health check endpoint. We're getting the temporal server address from config. This is setting up our actual temporal client and registering it as a service. And then really the most interesting thing here is this endpoint. It's a post endpoint forward slash customers where we send our requests for. id and v checks effectively so we pass in the details of the customer and we're also injecting a temporal client as well this part here is just kind of setting up the id for the workflow and the customer as well which is basically the same thing we are setting our review time out we can pass that in this body here so that's how i was tuning those levers or it just falls back to the default but really the the interesting part comes when we make use of our temporal client and we call this start workflow async method on that and as you can see here start workflow async and queues the workflow on the task queue and returns as soon as temporal has persisted the start event so that means that this is really suited to long running workflows we don't expect the workflow to return immediately we expect it to potentially take some time which makes sense here because this was a potentially a human in the loop process here we pass in the workflow that we're wanting to work with so the onboarding workflow and then we call the run async method with our inputs and then we create a new workflow options object on the fly with our workflow id that we constructed above and the name of the queue that we want to put that or we want to start that workflow on and then we just return a http 202 which is relatively standard practice for async apis to say that successful we've accepted the request but we don't yet have a result for you so at this point we've kicked off or requested the temporal server starts this workflow and registers our customer for a kyc check all right so take a quick pause there we'll come back and then we'll take a look at the workflows and activities project so let's move on now and take a look at our application project which contains the code for our workflows and our activities now from a c-sharp perspective this is the class library it's just code okay it doesn't actually run as of itself that is done by the worker so it's just pure workflow code and again that's where you define your business logic in this case that would be for the kyc flow if you look at the csproj file to see the kind of references that have been brought in of course we have a reference to Temporal. We have some stuff around Postgres, that's because we're making calls to our Postgres database, as well as stuff around HTTP client factory, and that's because we're making HTTP calls to our API endpoints. And that's all done from our activities. Now, in fact, before we move on to looking at our workflow, let's look at our activities. Okay, so they're in here onboarding activities, and we just have a number of activities, as you've seen before in the demo, these names should be relatively familiar to you. So for this, for example, this one here, verify identity async, this activity is just making a call to our mock ID and vService and it gets a result. Now it can fail as any API call can fail in any number of ways, but Temporal takes care of that. And the only Temporal specific code really is the fact we've decorated this method with the activity attribute that's it it's the same for all of these things this one here is just updating a database that's it okay so nothing terribly dramatic and in fact the code inside the method is just standard c-sharp code the only temporal specific stuff is again the fact these methods are decorated with this activity attribute now when an activity fails that's where the power of temporal kicks in it will be Those arrows will be taken by the worker and they'll be fed back to the temporal server and the server will then decide what to do with it based on any retry policies that are defined for these activities, which brings us nicely on to looking at our workflow. So let's come over to our workflow and The workflow defines the flow, the orchestration of our activities, basically. So you'll see how that all hangs together in just a minute. So here we have one workflow, onboarding workflow. It's just a standard C-sharp class decorated with the workflow attribute. And that means the temporal worker will treat it, number one, as a workflow, and it also expects it to run in a deterministic way. If you scroll a bit further down, we've got some private fields that you would find in any standard C-sharp class that just track various things about the workflow, but these private fields form part of the workflow's durable state. What does that mean? It means that, as we've seen, if a worker crashes, when it restarts, the value of these fields will be replayed from the temporal server's history and refreshed in that way, so you don't end up with duplicate calls being made for ID and V-checks and all that kind of stuff. Now the workflow itself starts or is entered here with the method called runAsync in this particular case, but it's decorated by the workflow run attribute. We were talking about retry policies here. So again, talking about the ID and V service, this is the retry policy that we've defined for it here or specifically here. And you can see amongst other things, we are going to attempt that service three times. Okay. And contrasted with our database writes the database is a system we own we've set the maximum number of attempts to zero which means it will retry infinitely and so aside from defining these very simple and straightforward retry policies and defining other options on our activities you do not have to write any retry codes temporal takes care of all of that for you okay So if we come a bit further down, we will actually see our first call to that particular activity, verify identity async that we just looked at a minute ago, and we call the execute activity async method on the workflow and pass in whatever options we want to work with. It's then simply a case of working with the results that are fed back from that particular service. In this case, if it was approved, then we call another activity, activate customer, and that's basically the end of our happy path workflow that we saw in our demo. Of course, that's not always the case, and if we get our needs review result back from the IDNB service, then we want to do two things. We want to record that in our system database so that will be propagated through to the front end, and we also want to notify the compliance officer. Then, of course, we go into a wait state. It's now a human in the loop waiting game for the compliance officer to do something. And of course, as you can see here, the loop will just look round until the compliance officer has made a decision. Of course, escalations can also occur within that loop as well. And that's what you can see here with a call to escalate async. The rest of this stuff is relatively standard. It's just if it's approved or if it's declined, that's fine. If it's rejected, that's kind of like the automated unhappy path. The ID and D service decides that person's rejected. It just calls that particular activity. Nothing particularly interesting about that. And then down here, we have our signal definition. This is just allowing the human in the loop to complete by allowing a compliance officer to send a signal from our client through into our workflow to give us a completed task status we also have something called a query and that allows our client in this case our compliance console to actually get live data from the temporal server as well So basically the takeaway point here is workflows define your business logic and they are deterministic. So if they were to run again after some kind of failure, they must produce the same kind of result. Activities work on things that are non-deterministic and can produce random results that you may not expect. So with that, let's move on to looking at our last project, which is our worker. So the last project we'll take a look at is our worker project. And as you'll remember, this is responsible for executing our workflow. If we just jump straight into the code, you can see we've only got a single program CS file in here. The code's not that long. It's like 55 lines. So there's not a whole lot to it. And in fact, all of this stuff up here, again, is nothing temporal specific. Here we're just... registering a connection to a database. Here we're pulling in some stuff with config. Here we're registering a HTTP client. So nothing temporal specific. That only happens down here where we are registering our temporal worker as a service. And we pass in our temporal server location, which in my case was just a local server running on my laptop, the namespace, and the queue that we want to put work onto, in this case, onboarding. And then finally, we just register our workflow. or workflows in this case we just have one as well as where we can find our activities that's it we then build the host and we run it this set of steps here is just migrating to our database in case that hasn't already occurred so all in all in terms of our projects it's probably the simplest of our projects but absolutely critical of course well that brings us to the end of today's video i hope you found it interesting and hopefully insightful in the description below i've put links to the temporal website which is a great place to learn more about our sdks and temporal generally i've also put a link to the code that you can download and run yourself, the same code that we used today. And I'll pop our QR code up on screen as well, linking off to our Slack community. If you're interested in learning more about Temporal, our Slack community is a brilliant place in which to engage with other like-minded people. Until the next video, stay safe and I'll see you around.

The Know Your Customer (KYC) process is a critical part of financial services and plays a key role in fraud prevention. Before a customer can access many financial products, organisations must verify their identity and assess potential risk.

In this video, we explore how to implement a durable KYC process using Temporal. Rather than focusing solely on the business workflow, we'll examine how Temporal helps build resilient, long-running systems that can survive failures and continue operating reliably.

Topics covered include:

- Modelling the KYC process as a Temporal workflow
- Long-running workflows and human-in-the-loop approvals
- Durable timers for SLA monitoring and escalation
- Retry policies for recovering from transient database failures
- Workflow replay and recovery when a worker process crashes
- Building fault-tolerant business processes that remain reliable over time

Whether you're new to Temporal or looking to understand how durability applies to real-world business processes, this video provides a practical, end-to-end example.

---
Time codes
- 0:49 - Video outline
- 1:50 - KYC process overview
- 2:52 - Demo scenario 1 - happy path
- 4:25 - Demo scenario 2 - Manual review
- 7:25 - Demo scenario 3 - Escallation
- 9:04 - Solution components
- 11:35 - Failure scenario 4a - Take down the DB (Retry Policies)
- 14:22 - Failure scenario 4b - Take down the worker (Durable state)
- 16:56 - Code walkthrough - API Project
- 19:55 - Code walkthrough - Workflow and Activities
- 25:47 - Code walkthrough - Worker project
- 27:02 - Final thoughts
---

Temporal is the simple, scalable, open source way to write and run reliable cloud applications. 

Learn more
Blog: https://temporal.io/blog
How Temporal Works: https://temporal.io/how-temporal-works
Community Slack: https://temporal.io/slack

Developer resources
Code: https://github.com/temporal-community/finance-example-durable-kyc-flow
Docs: https://docs.temporal.io
Courses: https://learn.temporal.io/courses
Support forum: https://community.temporal.io