Ongoing review technology
Run scheduled risk-based review and event-driven perpetual KYC from the same engine. The platform holds your review calendar, monitors configured change signals across the customer population, converts them into triggers under your rules, and routes a targeted refresh rather than re-papering the whole file.
- Scheduled risk-based review points and event-led triggers operated together.
- Continuous screening and configured change signals across the population.
- Targeted refresh of what changed instead of a full file rebuild.
- A record of why each review happened, not just that it did.
Where cycle-based review falls down, and where it does not
A word of caution before the sales case. UK requirements do not prescribe a single universal review interval, and they do not declare cycle-based review obsolete. Firms must keep customer due diligence information current and conduct ongoing monitoring on a risk-sensitive basis. Most firms meet that through a combination of event-led review and scheduled review points. Our regulatory answer on whether periodic reviews are required sets out the position with its sources.
What cycle-based review alone struggles with is timing. If a customer's ownership changes in month two and the review falls in month eleven, the file is out of date for nine months and the firm has no record that it knew. Meanwhile, effort is spent re-examining customers where nothing has changed at all.
The practical problem with moving to an event-led model is rarely the concept. It is the plumbing: detecting change reliably, defining triggers precisely enough to be operable, sizing the resulting workload, and evidencing that a customer with no triggers was genuinely monitored rather than simply ignored.
What the technology supports
The trigger model is your firm's policy decision. The platform detects, applies and evidences it.
Continuous screening
Ongoing sanctions, PEP and adverse media screening across the customer population, with your matching rules applied before an alert reaches a queue.
Change signals from source data
Monitoring of configured attributes such as registry status, ownership structure and entity details, so a change in the underlying record can be detected rather than waited for.
Configurable trigger taxonomy
Triggers defined by your policy across customer change, ownership change, screening outcome, geography and internally raised doubt, each with its own severity and response.
Proportionate response routing
A trigger drives a proportionate action, from an automatic data refresh through to a full enhanced review, rather than every event producing the same workload.
Targeted CDD refresh
Refresh the elements affected by the change, with the rest of the file carried forward and the reason for carry-forward recorded.
Risk reassessment on change
Where a change affects a risk factor, the customer risk rating is recalculated and, where your rules require, routed for review.
Risk-based periodic review scheduling
Scheduled review points held against the customer record and driven by risk rating and customer type, so the periodic cycle your policy defines is operated by the platform rather than tracked in a spreadsheet.
Retained review points alongside triggers
Scheduled review and event-led review run together rather than one replacing the other by default, with a trigger able to bring a scheduled review forward and a completed review able to reset the clock.
Ongoing monitoring evidence
The record shows what was monitored, what was detected, what was assessed as requiring no action, and what was actioned.
Transition from a periodic model
A population can be brought to a common standard first and then maintained by trigger-led review, so the move does not depend on files that were already out of date.
Scheduled review and event-led review, side by side
| Periodic (scheduled) review | Perpetual (event-led) review | |
|---|---|---|
| What starts a review | A date reached, set by risk rating and customer type. | A defined change detected against the customer, its ownership or its screening position. |
| Scope of work | Usually a full file refresh against the current standard. | Targeted refresh of the elements affected, with the remainder carried forward and the reason recorded. |
| Timing risk | A change between review dates is not picked up until the next cycle. | Depends on the coverage and precision of the configured signals and triggers. |
| Workload profile | Predictable and plannable, but spent partly on customers where nothing has changed. | Variable and event-shaped, concentrated on customers where something has changed. |
| Evidence burden | Show that the cycle completed and what it found. | Show what was monitored, what was detected, what needed no action and why. |
Neither column is a regulatory requirement in itself. The requirement is that customer due diligence is kept current and that monitoring is risk-sensitive; the mix of scheduled and event-led review your firm adopts is a documented policy decision. Our source-backed answer on periodic reviews sets out the position.
Where ongoing review sits in the wider platform
Ongoing review uses the same engine as onboarding and remediation, so a customer keeps one record and one audit trail across the lifecycle. The full lifecycle view is on the CDD platform page. Where the existing population has drifted from the current standard, firms establish a baseline first using KYC remediation technology. The rating that determines review frequency and trigger sensitivity is configured through customer risk assessment, and the queues that handle triggered work through KYC workflow.
Controls and evidence
Event-led review shifts the evidential burden. It is no longer enough to show that a cycle completed.
Evidence of monitoring, not only of review
For customers with no triggers, the record shows what was monitored and when, so an absence of review is explained rather than unexplained.
Versioned trigger rules
The trigger definitions and thresholds in force are versioned, so a reviewer can see the rules that applied at the time of a given event.
Attributable no-action decisions
Where a detected change is assessed as requiring no action, the assessment and the person or rule responsible are recorded.
Carry-forward provenance
Information carried forward in a targeted refresh retains its original source and date, so the age of each element is visible.
Coverage reporting
Reporting on which customers are under which monitoring configuration, so gaps in coverage are visible rather than discovered.
What firms use it to achieve
Firms move to this model to align the timing of review with actual risk change.
- Risk-relevant change is picked up when it happens rather than at the next scheduled date.
- Effort concentrated on customers where something has actually changed.
- A defensible account of ongoing monitoring for customers who were never reviewed in a period.
- Trigger volumes and response times visible, so the model can be calibrated on evidence.
- A structured route from a cycle-based model to an event-led one without losing existing evidence.
Implementation considerations
- Establish a current baseline first; event-led review maintains a population, it does not repair one that is already out of date.
- Define triggers precisely enough to operate, including what does not constitute a trigger.
- Model expected trigger volumes before go-live, because the workload profile changes shape rather than simply reducing.
- Decide explicitly which scheduled review points you are retaining and why, and document the rationale.
- Agree how monitoring evidence will be presented to internal audit and to your supervisor before you rely on it.
Related practitioner guidance
The regulatory position and the design detail are covered in our practitioner guidance, with primary sources cited there.
Periodic KYC vs perpetual KYC
How the two models differ and how firms move between them without losing evidence.
Does UK regulation require periodic KYC reviews?
Source-backed answer on review intervals and risk-sensitive monitoring.
KYC trigger events
A practical trigger taxonomy with detection and proportionate response.
What should firms do when beneficial ownership changes?
The steps that follow a detected ownership change.
Frequently asked questions
What is the difference between periodic KYC and perpetual KYC?
Periodic KYC reviews a customer at a scheduled point determined by risk rating and customer type, whether or not anything has changed. Perpetual KYC, sometimes called event-driven or continuous KYC, reviews a customer when a defined change is detected, such as an ownership change, a screening outcome or a change to the customer profile. They are not mutually exclusive: most firms run event-led triggers with a reduced set of scheduled review points retained for higher-risk segments.
Does perpetual KYC remove the need for any scheduled review?
Not automatically. UK requirements do not set a single universal interval, but they do require CDD to be kept current and monitoring to be risk-sensitive. Most firms retain some scheduled review points alongside event-led review; that is a policy decision for your firm, documented and justified.
Can the platform run scheduled periodic reviews on their own?
Yes. Review points can be scheduled by risk rating and customer type and operated on their own, with event-led triggers introduced later. Firms commonly start with the scheduled model already in policy and add triggers segment by segment.
What kinds of change can be used as triggers?
Triggers are configured by your policy and can be drawn from continuous sanctions, PEP and adverse media screening outcomes, registry and entity change signals such as status or filing changes, ownership and control changes, changes to the customer profile or product usage captured in your data, a change in the calculated risk rating, and doubt raised internally by a reviewer.
How is monitoring evidenced for a customer with no triggers?
The record shows what was monitored, over what period and under which configuration, so the absence of a review is explained by evidence of monitoring rather than by silence.
Can we move to this model with an out-of-date population?
You can, but it is rarely wise. Event-led review maintains a baseline. Where the population has drifted, firms usually establish a current baseline first, which is where the remediation technology is used.
Next step
Design the trigger model before you buy the technology
The productive first session is about your review calendar, your trigger taxonomy, your expected event volumes and your monitoring evidence. We will show how each would be configured and what the resulting record looks like.