How a KYC team stops refreshing customer risk files with guesswork
A Nordic bank's KYC function runs periodic due-diligence refreshes across thousands of customers a year. KnowledgeHub assembles each refresh file from source documents, screening hits, and prior reviews with full lineage, so analysts sign off on evidence instead of re-collecting it.
The refresh backlog
Periodic KYC review is simple in principle: every customer gets re-checked on a schedule set by their risk rating. In practice, each refresh means pulling documents from the onboarding system, screening results from a separate tool, ownership filings from a registry, and notes from the last review, then assembling them into a file a supervisor can sign.
Done by hand, this takes long enough that reviews queue up. Higher-risk customers wait alongside lower-risk ones for the same analyst time. And a risk-relevant change — new adverse media, a change in beneficial ownership — that happens between scheduled reviews often isn't caught until the next one comes around, calendar-driven rather than risk-driven.
The backlog isn't a productivity problem. It's a gap between when risk actually changes and when the bank notices.
Re-architecting the workflow
KnowledgeHub is deployed as a semantic layer above the onboarding system, the screening tool, and the ownership registries, nothing is replaced. Each source is ingested with lineage preserved at the document level. A versioned ontology defines the relationships between a customer, its beneficial owners, and the risk indicators that matter.
Refresh triggers are no longer only calendar-driven. A screening hit, an ownership filing, or a risk-rating change on any linked entity can start a refresh directly. Agents are given the bounded task of assembling the refresh file, retrieving the relevant documents, screening results, and prior notes with every item in the file cited to its source.
The analyst doesn't collect the file. The analyst reviews it.
Inside the analyst's day
An ownership filing updates for a corporate customer, and a refresh triggers before the scheduled review date would have.
KnowledgeHub retrieves what's changed and what's relevant: the updated filing, the customer's screening history, and the prior review's notes on the same ownership structure. The refresh file arrives ranked by relevance, each item tagged with its source and ingestion date.
The analyst's job is to evaluate what's been assembled, not to go find it. Where the ownership change raises the customer's risk profile, the analyst escalates with the evidence attached. Where it doesn't, the analyst signs off, and the file, with its full citation trail, is ready if it's ever reviewed again.
What changed
Faster refresh cycles are the visible benefit. Risk-driven rather than calendar-driven reviews are the structural one.
The backlog didn't disappear because analysts work faster. It shrank because most of what used to be manual assembly is now review. And risk-relevant changes that used to wait for the next scheduled review now start one directly.
When a regulator asks why a customer's risk rating changed on a given date, the answer is the filing that triggered it and the analyst who reviewed it.
Related use cases
Easy to start. Safe to stop.
The pilot runs at a fixed price: we map the workflow, deploy it in your environment and prove it on your own cases. Then you decide.
Fixed price · Fixed timeframe
- 01
Map the workflow
Two weeks with your people where we document what happens today, including the parts nobody wrote down.
- 02
Deploy in your environment
Inside your tenancy, on your data residency terms, with no exports and nothing leaving through the side door.
- 03
Prove it under audit
Controlled evaluation against your own cases with compliance and the process owner signing off before go-live.
- 04
Run in production
We stay on with retraining, reporting and ongoing oversight for as long as the workflow runs.
Fixed price, Fixed timeframe. 8–12 weeks pilot: Continue (Expand once you know it works) / Stop.