Periodic KYC vs Perpetual KYC: What UK Firms Need to Know

Periodic KYC reviews a customer file on a fixed cycle set by risk rating. Perpetual KYC replaces most of that cycle with continuous monitoring of defined data signals, opening a review when something relevant changes. UK regulation does not mandate either model: it requires that due diligence information stays current and that monitoring is conducted on a risk-sensitive basis.

What each model actually means

In a periodic model, every customer carries a review date derived from their risk rating. When the date arrives, an analyst refreshes identification data, ownership, screening and risk assessment, and records a decision. Work volume is predictable because it is scheduled.

In a perpetual model, sometimes written as pKYC, the firm defines the data points that matter for each customer segment and monitors them. A change in one of those data points opens a targeted review of what changed, rather than a full refresh of the whole file. Work volume follows real-world events, which makes it less predictable but more closely aligned to risk.

Regulatory basis, stated carefully

The Money Laundering Regulations 2017 set the statutory framework for customer due diligence and ongoing monitoring. HMRC guidance for supervised businesses describes ongoing monitoring as including keeping customer due diligence and beneficial ownership information current, scrutinising transactions for consistency with what the firm knows about the customer, and acting on triggers such as changed circumstances, unusual activity, relevant geographic risk changes and doubts about previously obtained information.

In April 2026 the FCA published findings from a multi-firm review of customer due diligence processes and controls. Among the weaknesses it observed were insufficient detail in procedures covering periodic and event-driven reviews, failure to record the purpose and intended nature of the relationship, insufficient evidence of enhanced due diligence measures, and weak independent assurance and version control. Stronger practice it described included risk-tailored due diligence, documented enhanced due diligence steps and regular independent testing.

Two points of nuance are worth stating plainly. First, requirements and supervisory expectations differ by sector, supervisor and firm risk profile; FCA findings describe what the FCA observed in the firms reviewed rather than a uniform rule for every business. Second, nothing in the statutory framework names a fixed universal review interval, so a firm's review cadence is a risk-based design decision it must be able to justify. This page is general information, not legal or compliance advice.

Comparing the models honestly

Where periodic review holds up

• Predictable capacity planning and straightforward management reporting.
• Simple to explain, document and test.
• Workable where customer data is unstructured or external signals are thin.
• Gives every file a guaranteed point of human attention.

Where periodic review struggles

• Risk-relevant change is only detected at the next scheduled date.
• Effort is spread evenly across files rather than concentrated on change.
• Cycles slip, producing the backlogs that drive remediation programmes.
• Full refreshes re-collect information that has not changed, which irritates customers.

Where an event-driven model holds up

• Review effort tracks actual change in ownership, behaviour, screening status or geography.
• Files stay closer to current between formal touchpoints.
• Outreach becomes targeted, which raises response rates.
• Trigger reporting itself becomes useful management information about the book.

Where an event-driven model struggles

• It is only as good as the data feeding it, and silent feed failure is a real control risk.
• Volumes are lumpy, so capacity planning is harder.
• Trigger logic becomes a governed control that needs versioning and testing.
• Absence of a trigger has to be evidenced as a deliberate outcome, not an accident.

Designing an event-driven model

A workable design usually has five components, each of which needs an owner and documentation.

• Signal inventory. The data points monitored per segment: registry filings, ownership changes, address and status changes, screening list updates, adverse media, transaction patterns, product changes, jurisdictional exposure.
• Trigger logic. The rules translating a signal into an action, with materiality thresholds so that immaterial changes do not generate a review. See KYC trigger events for a fuller taxonomy.
• Review scoping. What a triggered review covers. A change of beneficial owner should re-verify and re-screen the new party and reassess risk; a change of trading address may only need a data refresh.
• Backstop cadence. A long-stop interval per risk band so no file goes indefinitely without human attention, however quiet the signals are.
• Assurance. Testing that triggers fire when they should, that they are worked within timescales, and that outcomes are of acceptable quality. See KYC quality assurance.

A realistic transition approach

1. Establish a clean baseline. Event-driven review of an inaccurate file propagates the inaccuracy.
2. Structure the data. Triggers cannot evaluate information held in scanned documents and free text.
3. Run triggers in observation mode alongside the existing cycle and compare what each finds.
4. Release segment by segment, starting where data coverage is strongest.
5. Retain the periodic backstop and only lengthen it once trigger performance is evidenced.
6. Document the change of model, its rationale and its approvals as a control change.

Common pitfalls

• Treating perpetual KYC as a product purchase rather than an operating-model change.
• Retiring the periodic cycle before trigger coverage has been tested.
• No alerting on data feed failure, so silence is read as no change.
• Triggers with no materiality threshold, producing a review queue nobody can work.
• Changing trigger configuration without version control, which the FCA specifically flagged as a weakness in its 2026 findings.
• No record of why a signal did not result in a review.

How technology supports this

Automation can monitor signals, open and route reviews, refresh registry and screening data, assemble evidence and report on trigger performance. It does not absorb accountability: whether evidence is sufficient, how to treat a discrepancy and whether to escalate remain decisions for an accountable person. The Agora Due Diligence Platform supports perpetual KYC, screening, ownership resolution and case reporting with the configuration under the firm's control and an audit trail across each step.

Primary sources

• FCA, Firms' customer due diligence processes and controls: our findings (8 April 2026)
• HMRC AMLG11411, ongoing monitoring (updated 16 July 2026)
• HMRC AMLG11300, customer due diligence (updated 16 July 2026)
• The Money Laundering, Terrorist Financing and Transfer of Funds Regulations 2017

Frequently asked questions

Related resources

Where the technology fits

Agora is a technology provider: the platform supports the control described above, and your own teams operate it and hold the accountable decisions.

• Perpetual KYC softwareContinuous screening and change signals feeding targeted CDD refresh.
• KYC remediation softwareEstablishing a current baseline before an event-led model can be relied on.