Refresh is an operations problem wearing a compliance badge
The population is calculable: customers whose risk rating and last review date make them due. The work is repetitive: request documents, chase, verify, escalate anything that does not fit. The failure mode is boring: it slips, and slippage is only visible once the overdue count is large enough to be a finding.
Treated as a workflow with owners, ages and escalation, refresh stops being an annual panic. Treated as a spreadsheet, it always becomes one.
What the workflow does
- 01Builds the due population from risk rating, entity type and last review date, on a schedule.
- 02Assigns by risk and workload, with a queue per team and a visible age per case.
- 03Requests and tracks the standard document set for the entity type, and chases on a cadence you configure.
- 04Escalates anything unusual to a reviewer rather than letting it sit in an analyst queue.
- 05Records the completed review with its evidence, its approver and the policy version in force.
Entity complexity is where tooling earns its keep
| Case type | What makes it slow | What automation removes |
|---|---|---|
| Individual, low risk | Volume | Document chasing and manual queue building |
| SME with a simple structure | Document collection | Requests, reminders and completeness checks |
| Corporate with layered ownership | Ownership tracing | Nothing about the judgement, everything about the tracking |
| Trust or partnership | Non standard documents | Standardized evidence checklists per type |
| Politically exposed relationship | Enhanced review and approval chain | Routing, escalation and approval enforcement |
The line we will not cross
Automation prepares, requests, routes, tracks and evidences. It does not decide whether a customer relationship is acceptable, and it does not clear a review. A person makes that call, an approver confirms it, and both are recorded.
Building the due population, which is the whole game
Everything else in refresh depends on whether the due population can be calculated rather than estimated. It is a function of three inputs: the risk rating, the date of the last completed review, and any event that triggers an off cycle review. If those three can be queried together, the overdue number is a fact that updates itself. If any one of them lives in a spreadsheet, the number is an estimate, and an estimate is what an examiner will test first.
| Input | Usually lives in | What goes wrong |
|---|---|---|
| Risk rating | Customer or CRM system | Rating changes without moving the review date |
| Last review date | Case system, sometimes a spreadsheet | Recorded when the file closed rather than when it was approved |
| Event triggers | Monitoring output, relationship notes, email | Never reaches the refresh queue at all |
| Cadence rules | The policy document | Not expressed anywhere a system can read |
The refresh backlog, and how it forms without anyone deciding
Periodic refresh backlogs are rarely created by a decision. They form because the population that becomes due each month is calculated from risk ratings and onboarding dates that were set years apart, so the due volume arrives unevenly while the team size does not change. A quiet quarter is followed by one where three times the normal volume falls due, and the overflow becomes a backlog that never fully clears because the next uneven quarter arrives before it does.
Making the due population visible several months ahead turns that from a recurring surprise into a capacity plan. The same view also shows which segments are generating the volume, which is usually where the outreach process, rather than the analysis, is the constraint. A refresh that is waiting on a customer to return a document is not the same item as one waiting on an analyst, and counting them together produces a backlog number that cannot be acted on.
The fourth row is the one most often overlooked. A cadence that exists only in prose has to be applied by a person, and people apply prose inconsistently. Expressed as configuration, the cadence applies itself and a change to the policy changes the population the same day.
Chasing, which is most of the elapsed time
A refresh case is rarely slow because the review is hard. It is slow because a document was requested, nothing came back, and three weeks passed before anybody noticed. The elapsed time in most refresh operations is dominated by waiting, and waiting is the easiest thing in the whole program to automate without touching a decision.
- 01Request the document set derived from the customer type and jurisdiction, rather than assembled by hand.
- 02Chase on a schedule, with escalation to the relationship owner after a defined number of attempts.
- 03Track the request as an item with an age, so a stalled case is visible without a person reviewing the list.
- 04Check completeness and expiry automatically, so a file does not reach an analyst missing a document or carrying an expired one.
- 05Record every request, every chase and every receipt, because that record is what proves the effort was made when a relationship has to be exited.
The exit conversation nobody plans for
Some refresh cases end with a customer who will not or cannot provide what is required. Exiting a relationship is a serious step and it is frequently delayed, not because the decision is unclear but because the evidence of reasonable effort has to be assembled before anybody is comfortable taking it. When every request, chase and escalation is already an item with a timestamp and an actor, that evidence exists the moment it is needed, and the decision gets made on its merits instead of on how much work the paperwork would be.
Measuring the queue honestly
- Overdue population, by risk rating, reported as a count and as a proportion of the due population.
- Age of the oldest overdue case, which is the number that embarrasses a program fastest.
- Elapsed time split into waiting on the customer and waiting on the bank, because these have different owners.
- Cases reopened after completion, which usually indicates a completeness check that is not being applied.
- Proportion of cases triggered by an event rather than by the calendar, which shows whether triggers work at all.
For the program level view around this queue, see AML compliance software, and for the alert side of the same operation, BSA AML monitoring software.
Questions about kyc software for banks
Do you perform identity verification or screening?
No. Screening and verification stay with the providers you already use. This orchestrates the work around them: what was requested, what came back, what is missing, who reviewed it and who approved.
Can refresh cycles differ by risk rating?
Yes, cycles and evidence requirements are configured per risk rating and entity type, and changes to them are versioned and approved like any other rule.
How does this connect to our customer system?
By scheduled export or API from the system of record, the same file-first approach used everywhere else in the product. The customer master stays where it is.
What does the evidence pack contain?
The review, the documents collected, the checks recorded, the rationale, the approver, the timestamps and the policy version in force at the time. Exportable per customer or per population and period.