Perpetual KYC (pKYC): Replacing the Periodic Review Cycle
The periodic review cycle — high risk annually, medium every three years, low every five — is an artefact of a time when refreshing a customer file meant posting a form and waiting. Perpetual KYC replaces the calendar with a trigger: the file is reviewed when something about the customer actually changes.
What actually changes
Under periodic review, the question is when is this file next due? Under pKYC, it is what would have to change for this file to need attention, and would we notice?
That second question is harder, and it reframes the programme. You are no longer scheduling work; you are instrumenting a customer base. The review itself barely changes — the same CDD standards, the same risk rating methodology. What changes is what initiates it.
Crucially, pKYC is not "review everything continuously". That would cost more, not less. It is "review nothing until something warrants it, and be confident you would detect that something".
The trigger taxonomy
Triggers fall into four families. A programme that implements only the first is not doing pKYC; it is doing screening with extra branding.
Screening triggers
A customer or connected party appears on a sanctions list, becomes a politically exposed person, or attracts adverse media. These are the easiest to implement because the infrastructure already exists — ongoing screening is a baseline obligation, not a pKYC innovation.
Behavioural triggers
Transaction activity diverges from the profile the file was built on: volume, value, counterparty geography, product mix, or velocity. This is where pKYC earns its keep, and where it needs your monitoring platform to emit profile-deviation signals rather than only suspicion alerts. The two are different outputs and most systems only produce the second.
Static-data triggers
Registered address, legal form, directors, or beneficial ownership changes at a corporate registry. This requires a registry data feed with change notification — not a lookup you perform at onboarding and never repeat. For corporate portfolios this is usually the highest-value trigger family and the most commonly skipped.
Relationship triggers
The customer takes a new product, changes a mandate, adds an authorised signatory, or alters a payment pattern that changes their risk profile. These originate in core banking, not in the compliance stack, which is why they are the hardest to wire up politically.
Data prerequisites
Three things must be true before pKYC will work. Firms that skip the assessment tend to discover them in production.
- A single customer view. If a customer exists as four records across three systems, triggers fire against fragments and reviews miss context. This is usually the longest lead-time item in the programme, and it is not a compliance project.
- A structured customer profile. Expected activity must be stored as data — thresholds, geographies, counterparty types — not as free text in a case note. You cannot detect deviation from a paragraph.
- An event bus or equivalent. Something must carry signals from core banking, screening, monitoring and registry feeds into the review queue. Nightly batch is workable; a fortnightly extract is not.
Retiring the backlog
Almost every firm adopting pKYC is carrying an overdue periodic review population. Switching the calendar off does not clear it, and regulators will ask what happened to it.
The defensible sequence is to run both models in parallel for a defined period. Keep the calendar running for the existing backlog while pKYC triggers operate across the whole base. Work the backlog in risk order, not date order — an overdue high-risk file matters more than an older low-risk one. Then retire the calendar only for populations where trigger coverage has been evidenced.
That last clause is the one examiners probe. "We moved to event-driven review" invites the question how do you know your triggers would have caught the things your calendar caught? The answer is a back-test: replay the last cycle's reviews and establish what proportion would have been initiated by a trigger. Where the answer is low, either the trigger set is incomplete or the calendar was generating work of little value. Both findings are useful; neither is a reason to skip the test.
Governance and evidence
A pKYC programme needs three artefacts that a periodic programme does not. A documented trigger catalogue, owned and version-controlled, stating what each trigger detects and why the set is adequate. Coverage monitoring, showing triggers are firing at expected rates — a trigger that stops firing is indistinguishable from a quiet portfolio until you look. And exception reporting for customers where no trigger has fired for an extended period, which is the residual safety net that replaces the calendar.
That third artefact matters more than it sounds. A dormant file that never triggers is not necessarily low risk; it may be a file whose data feeds are broken.
Where to start
Do not start with technology. Start by back-testing one completed review cycle against a draft trigger catalogue. That single exercise tells you how much of your current review effort is being spent on files where nothing had changed — typically the large majority — and it produces the business case, the trigger gaps, and the data-quality findings in one pass.
Related: watchlist rescreening frequency covers the screening-trigger family in more depth, and KYC onboarding automation covers the front end of the same data problem.
Sequencing a pKYC Rollout
Attempting the whole customer base at once is the most common way these programmes stall. A phased sequence keeps the risk contained and produces evidence at each stage.
Phase one: one segment, triggers in shadow
Pick a single, well-understood segment — often domestic retail, because the data is cleanest — and run the trigger set in shadow mode. Triggers fire into a log rather than a work queue. Nothing changes operationally, and within a cycle you have a measured firing rate per trigger and a clear view of which are noisy.
Phase two: tune before you switch anything off
Triggers need tuning exactly as monitoring rules do. A trigger firing on 40% of a segment every month is not a trigger; it is a description of normal behaviour. Tune against the shadow data until firing rates are plausible and the reviews they would have produced are defensible.
Phase three: parallel run
Run triggers live alongside the existing calendar for at least one full review cycle on that segment. This is the evidence an examiner will ask for: a documented comparison showing what the calendar found, what the triggers found, and the overlap. Where triggers missed something the calendar caught, the gap is a trigger you have not built yet.
Phase four: retire the calendar, segment by segment
Only retire periodic review for a population once its trigger coverage has been evidenced. Retiring it wholesale because the programme is "live" is the decision that turns a sound initiative into a finding.
What to Measure Once It Is Running
A pKYC programme needs a different management information set from a periodic one, because the thing that can go wrong is different. Under a calendar, the failure mode is falling behind. Under triggers, it is silence.
Firing rate per trigger
Track each trigger separately, monthly. A rate that collapses is usually a broken feed rather than a quiet portfolio, and nothing in the review queue will tell you — the queue simply looks manageable. Set an expected range per trigger at tuning and alert on departures from it in either direction.
Time from event to review
The entire argument for pKYC is that risk-relevant change is acted on promptly. Measure the interval between the underlying event and the completed review, not between the trigger firing and the review. A registry change detected six weeks late through a monthly batch has already lost most of the benefit.
Dormant population
Report the count of customers for whom no trigger has fired in a defined period, split by risk tier. High-risk customers appearing in that report warrant investigation of the data, not reassurance about the customer.
Outcome quality
Track the proportion of triggered reviews that result in a rating change, an EDD escalation or a report. A trigger set producing reviews that never change anything is generating work without generating risk reduction, and should be retuned rather than defended.
Move From Periodic Review to Continuous
One Constellation ties screening, monitoring and registry signals into a single trigger layer — so a file is reviewed when something actually changes, not when the calendar says so.
