Risk assessment refresh: documents to prepare
A risk assessment refresh checks whether your customer, product and delivery-channel risk ratings still match reality. Before the review starts, gather the customer files, transaction history, ownership records and the prior assessment report that shows what has changed since the last cycle. Missing files delay the sign-off, not the review itself.
Why the refresh is triggered
A refresh is not a one-off exercise. It follows a periodic cycle set out in each entity's own risk-based policy, and that cycle runs alongside event-driven triggers. A new product, a new market, a change in ownership or control, or a supervisory request can all bring the refresh forward, regardless of where the entity sits in its normal schedule.
The mechanism is deliberately open-ended. A regulator does not publish a fixed list of triggering events; it expects each entity to recognise a material change and act on it without waiting for the next scheduled date.
What changes once the refresh starts
Once a refresh is opened, the existing risk rating stays formally in force until the new one is signed off. That sign-off is the point of no return: before it, staff continue to apply the old controls; after it, every open file inherits the new rating, including any enhanced due diligence that the new rating requires.
This matters for planning. A refresh that stalls halfway does not freeze the clock — it simply leaves the entity operating under a rating that no one currently defends.
Documents to prepare, step by step
| Document | Why it is needed | Where it comes from |
|---|---|---|
| Current risk assessment report | Gives the baseline the refresh will compare against | Internal compliance file |
| Customer due diligence files | Confirms whether the customer profile still matches the original rating | CDD file |
| Transaction and activity records | Shows behavioural change since the last cycle | Transaction monitoring system |
| Ownership and control records | Confirms no undisclosed change in beneficial ownership | Corporate registry extracts, self-certifications |
| Product and channel inventory | Confirms new products or channels are captured in scope | Internal product register |
| Prior regulator correspondence | Confirms any outstanding remediation point is closed | Compliance archive |
- Compliance officer pulls the current risk assessment and the change log since the last cycle.
- Business owner confirms which products, channels and customer segments have changed.
- MLRO compiles updated files for any segment flagged as higher risk.
- Compliance team cross-checks ownership records against the corporate registry.
- Senior management reviews the draft refresh and raises any objection before sign-off.
- Compliance officer records the sign-off date and files the refreshed assessment.
Who decides, and how long it takes
The compliance officer or MLRO prepares the refresh. Senior management, or the board where the entity's structure requires it, approves the outcome. A supervisory authority may ask to see the refresh during an inspection, but it does not set the internal timetable and does not sign it off in the entity's place.
How long the exercise takes depends on how many files must be revisited and how many of them sit in the higher-risk band. A refresh limited to a policy update moves quickly; a refresh that reopens a large share of the customer base does not.
Branches you are likely to meet
If the rating moves up for a segment, the enhanced due diligence file for that segment reopens, and sign-off waits until it closes.
If ownership has changed since the last cycle, updated beneficial-ownership documents become mandatory before the refresh can proceed to approval.
If the entity has added services that cross a border since the last review, the timing question resembles the one that arises when cross-border services are added authorisation the deadline that matter, and the refresh should not be signed off until that question is settled.
Similar decision points elsewhere in the practice
Unclear decision authority is not unique to a refresh cycle. It surfaces when the parties never agreed the territory in a licensing arrangement, and no one is quite sure who has the final say.
It surfaces again when damages are demanded without evidence, leaving a forum to fix the standard of proof rather than the parties themselves.
And it surfaces once more when open source is found in the delivery of a technology contract, well after the parties believed the file was closed.
What this page does not cover
This page describes the staging of a refresh, not the substance of any single risk assessment. It does not set out how to score a specific customer or product, and it does not replace a national procedural rule that may apply to a particular sector. Where the underlying customer file has never been built, the design of that file is a separate exercise, covered on its own page.
Related publications
For readers assembling the underlying file rather than refreshing an existing one, Customer due diligence design step by step covers that separately.
Verified
This page describes a procedure rather than a statutory provision, so it does not cite article numbers or regulation text. Checking a specific citation would require the national implementing layer of the registry, and that layer is not open for procedural pages of this kind. The staging described here reflects the sequence used across the practice and was reviewed by the author before publication.
FAQ
How long does risk assessment refresh take in practice?
It depends on scope. A policy-only update moves in days; a refresh that reopens a large part of the customer base runs longer, because each higher-risk file must close before sign-off.
Which documents are needed to start?
The current risk assessment, the customer due diligence files, transaction records, ownership records and the product inventory. Without these, the review cannot confirm what has actually changed.
What happens if the other side does not respond?
If a customer or counterparty does not respond to a request for updated information, the file stays open past its expected date. Many entities apply restrictions on the relationship until the missing information arrives, rather than signing off on an incomplete file.
Questions specific to your entity's own file are best raised through the contact channel on this site rather than answered in general terms here.