The KYC Refresh Process, and the Part That Should Stay Human on Purpose

The backlog you built for yourself

Your KYC refresh queue is behind. It is always behind. High-risk customers come due every year, medium-risk every two or three, and the analysts who work the queue spend most of their week re-requesting documents from customers who have not changed anything since the last time you asked.

So the perpetual KYC vendors arrive with a clean pitch. Stop reviewing on a calendar. Monitor continuously, refresh on events, and let a model decide which files need a person. Every pitch carves out one exception: the complex cases still go to a human.

Two parts of that pitch deserve a harder look. The first is the calendar itself, which you probably did not need. The second is the carve-out, which is drawn in the wrong place.

The schedule was never the rule

Here is the sentence most refresh programs are built without reading. In its CDD Rule FAQs, FinCEN states: "There is no categorical requirement that financial institutions update customer information on a continuous or periodic schedule. The requirement to update customer information is risk based and occurs as a result of normal monitoring."

A neighbouring answer goes further. Institutions "do not have an obligation to solicit or update beneficial ownership information as a matter of course during regular or periodic reviews, absent specific risk-based concerns."

Read those together and the one-, two- and three-year cycles look different. They are not a regulatory requirement. They are a control the bank designed, usually years ago, usually because a schedule is easy to evidence to an examiner. That is a reasonable thing to have done. It is not the same as being obliged to do it, and it is not a reason to spend money making it faster.

The regulators have not moved off this position. FinCEN's April 2026 proposal to restructure AML/CFT program requirements (fact sheet) moves ongoing customer due diligence under the internal policies, procedures and controls pillar and says plainly that the reorganisation is not meant to change the substance of the obligation. What it adds is emphasis on keeping the program tied to a current risk assessment. Risk drives the refresh. The calendar was always a proxy.

So the first question about automating KYC refresh is not which vendor. It is how much of the queue exists because risk changed, and how much exists because a date arrived. At most institutions we look at, nobody has counted. The answer decides whether you are buying automation for a compliance obligation or for a habit.

What the vendors get right

None of this means the refresh should stay manual. A lot of it should not.

Pulling a corporate registry record, re-screening against sanctions and adverse media, checking whether a beneficial owner's identification has expired, flagging an address change from the core: all of that is retrieval and comparison against data the bank does not own. Machines do it better than analysts, and every hour an analyst spends on it is an hour not spent on the part that needs them.

Event-driven monitoring is also a better design than a calendar on its own terms. A customer who changes ownership in month two of a three-year cycle is a risk for thirty-four months under the old model. That is the strongest argument for perpetual KYC, and it is a good one.

The disagreement is narrower than it looks. It is about what happens after the trigger fires.

The carve-out is drawn on the wrong axis

Every perpetual KYC vendor keeps a human in the loop for complex cases. Even PwC's own paper on the model concedes that the end state still leaves a subset of cases requiring human intervention, without saying which.

Complexity, in practice, means operational complexity. Layered ownership. Multiple jurisdictions. Trusts inside LLCs inside partnerships. Files that take a long time to assemble. Those are hard, and a person should look at them.

But the regulation does not define the trigger by how hard a file is to build. It defines it by whether the customer's risk profile has changed. Those are two different sets of customers. A sprawling family office structure that has looked identical for six years is complex and unchanged. A sole proprietor whose deposits tripled and started arriving from three new states is simple and changed. A complexity carve-out routes the first to a senior analyst and the second straight through.

That second customer is the one the whole regime exists for.

The judgement is about a story

What a person does well in KYC refresh is not reading documents. It is holding a story in their head. At onboarding the customer told you what the account was for. A landscaping business. A dental practice. A holding company for two rental properties. Every refresh after that is a test of whether the account still behaves like that story.

A model can tell you that behaviour has moved. Transaction velocity is up, counterparties are new, cash share has changed. What it produces is an alert, a score that says something is different. It cannot tell you whether the difference is a landscaper who won a municipal contract or a landscaper whose account is now moving someone else's money. Both look like growth. Only one of them has an explanation that holds together when you ask the customer about it.

That is the step to keep human, and to keep human on purpose. Not as the fallback when the model is unsure, and not because the file is big. Because deciding whether a story still holds is the judgement the obligation is actually asking for. When that decision is made by a threshold, the bank has not automated a review. It has automated the absence of one, and the audit trail will show a clean pass on exactly the account that needed a phone call.

We made a version of this argument about payments, where the fraud losses sit in the exception path rather than the automated one. The shape is the same here. Controls tend to get built around the population that is easy to process, and the risk collects in the population routed around them.

Why the wrong carve-out keeps getting built

It is not because vendors are careless. It is because complexity is measurable at intake and story change is not.

A vendor can count entities in an ownership chart before the review starts, so a complexity rule is easy to configure, easy to demo, and easy to show an examiner. Whether a customer's behaviour still matches their stated purpose can only be answered by someone who knows what the stated purpose was. At many institutions that information sits in a free-text field from onboarding, in a system the monitoring tool does not read.

So the carve-out gets drawn where the data is, not where the risk is. A throughput metric replaces a judgement metric, and the dashboard improves while the program's actual coverage gets thinner. It is the compliance version of looking for your keys under the streetlight because that is where the light is. The keys, in this case, are in the expected activity field nobody migrated.

There is a second-order cost. Analysts who spend years re-requesting unchanged passports stop being investigators. When the queue is automated around them and the remaining work is only complex files, the skill the bank needs most, recognising when a story has stopped adding up, has had no practice. Automation that removes the busywork should hand that time to the judgement work. Designed around complexity, it hands it to more paperwork.

What to decide before you buy

The questions that settle this are not about features. They are about your own program.

How much of your current refresh volume is calendar-driven, and could you defend shrinking it with a risk assessment rather than a vendor brochure? Where does the customer's stated purpose live, and can anything other than a person compare it to what the account does now? When a trigger fires on a simple customer, who decides whether the change is explained, and is that person allowed to say no?

If the answers are "we don't know," "a free-text field," and "nobody, it auto-clears below the threshold," the problem is not speed. Buying a faster version of that program gets you to the wrong answer sooner. The same sequencing logic applies to what a community bank should automate last in digital onboarding: automate the throughput, keep the decision that converts speed into loss. We have written more generally about when AI is the wrong tool, and this is a clean example. The retrieval is a machine's job. The verdict is not.

Where writing stops

An article can tell you that your refresh cadence is probably a choice rather than a mandate, and that the human carve-out in most perpetual KYC designs sits on the wrong axis. It cannot tell you what share of your queue is calendar noise, where your expected activity data actually lives, or what an examiner will accept from your risk assessment if you change the model.

That takes a week inside your program, not a vendor demo. If your KYC refresh backlog is the thing you are being asked to fix this year, and you want to know which part of it to automate and which part to protect, talk to us before you sign.