From Periodic Review to Perpetual KYC: An Implementation Blueprint
Periodic review exists because refreshing a customer file used to mean a person doing it. Once the triggers can be detected continuously, the calendar stops being a control and becomes a queue. This paper sets out a staged route from one model to the other, and the governance that has to come with it.
The periodic review cycle has an obvious weakness that everyone has learned to live with: a customer whose circumstances change the month after review continues at the old rating until the next one. In a three-year low-risk cycle that is a long time to be wrong.
It persisted because the alternative was not operationally possible. That has changed — but moving requires more than switching the schedule off.
What Actually Triggers a Reassessment
The design of the trigger set is the design of the control. Four categories:
- Screening events. A customer, beneficial owner or connected party appears on a sanctions, PEP or adverse media source — or is removed from one.
- Structural events. A change of beneficial ownership, directorship, registered address, or corporate status. These are the most under-implemented because they require registry data rather than internal data.
- Behavioural events. Transaction activity diverging from the profile the rating assumed — new corridors, materially changed volumes, new counterparty types.
- Contextual events. A jurisdiction changing status, a product change, or a regulatory reclassification affecting a whole cohort.
A programme built only on the first category is a rescreening programme, not perpetual KYC.
The Data Requirement
Event-driven review only works if the data that generates events is current and connected. In practice three prerequisites:
- Resolved ownership held as data, not documents. A PDF register cannot generate a change event. The ownership chain has to be structured.
- Continuous screening rather than point-in-time. Customers become PEPs, get designated and appear in adverse media between reviews — see rescreening frequency.
- A behavioural baseline. "Divergence from expected activity" requires expected activity to be recorded at onboarding and maintained.
Firms that attempt pKYC without these end up with a trigger set that fires on screening alone, and conclude the model does not work.
A Staged Route
Stage 1 — Run both
Keep the periodic cycle and add triggers alongside it. Measure what the triggers catch that the cycle would have missed, and how much earlier. This produces the evidence base for the governance case and exposes gaps in trigger coverage while the safety net is still in place.
Stage 2 — Extend cycles where triggers are proven
For cohorts where trigger coverage is demonstrably complete, lengthen the periodic interval rather than removing it. This is a documented risk decision, not a quiet configuration change.
Stage 3 — Event-driven with a backstop
Move to trigger-driven review with a long backstop interval — so a customer who generates no events is still looked at eventually. Most supervisors are comfortable with event-driven review; far fewer are comfortable with no periodic element at all.
Stage 4 — Continuous risk rating
The rating itself updates as inputs change, rather than being restated at review. This is the end state and should not be attempted before the trigger set is stable.
The Governance Question You Will Be Asked
"How do you know your triggers are complete?" There is no way to answer that from the triggers themselves. You answer it from testing:
- Back-testing. Take relationships where risk demonstrably changed and confirm the trigger set would have fired.
- Negative testing. Deliberately change data in a test environment and confirm the event is raised.
- Coverage mapping. Map each risk factor in the model to the trigger that would detect a change in it. Unmapped factors are your gap list.
- Change control. Trigger definitions are a control. Changes need approval and an audit record, exactly as monitoring scenarios do.
What Does Not Change
Perpetual KYC changes when review happens, not what review requires. Enhanced due diligence still requires senior approval, source of wealth and source of funds, and enhanced ongoing monitoring. Records still have to be retained. The reasoning behind a rating still has to be reconstructable.
The common failure is to treat automation as a reduction in evidential burden. It is the opposite: an event-driven model generates more decisions, more often, and each still needs a record.
The Transition Population
Every pKYC programme has a problem nobody plans for: the customers onboarded under the old model, whose files were built to a different standard and whose data was never structured for event detection.
These records typically lack the three things the new model depends on — structured ownership, a recorded behavioural baseline, and a rating with a reconstructable basis. Switching them to event-driven review does not work, because there is nothing for the events to fire against.
Three approaches, in decreasing order of cost and defensibility:
- Remediate on a risk-prioritised schedule. Bring high-risk and complex relationships onto the new data model first, then work down. Slowest, most defensible.
- Remediate at next natural touchpoint. Upgrade the record when the customer next interacts — a new product, a transaction review, a periodic review that was already due. Cheaper, but leaves dormant relationships unaddressed indefinitely, which is itself a risk.
- Run a hybrid indefinitely. Legacy population stays on periodic review; new population is event-driven. Operationally simplest and the hardest to defend, because two standards persist with no end date.
Whichever is chosen, it must be a documented decision with a timeline. The failure mode is drifting into the third option without ever deciding on it.
Technology Prerequisites, and Where They Break
Perpetual KYC is frequently sold as a configuration change. It is closer to a data architecture change, and four prerequisites decide whether it works:
A single customer record across products and entities. If the same natural person exists three times in three systems, an event on one does not reassess the others. This is the most common blocker and the most expensive to fix, because it is a master-data problem rather than a compliance one.
Ownership held as structured data. Change events require machine-readable ownership. A scanned register cannot generate a trigger.
Event infrastructure. Something has to detect a change, evaluate it against the trigger rules, and raise work. Batch overnight comparison is workable; nothing at all is not.
Audit capture at the event level. Each triggered reassessment is a decision and needs a record: what fired, what was evaluated, what changed, who approved. Firms that automate the reassessment but not its evidencing end up with a faster process and a weaker file — which is a poor trade under inspection.
Assess these four honestly before committing to a timeline. A programme that starts without the first one usually stalls at the point where it has to explain why events are not reaching every relationship.
Measuring Whether It Worked
Efficiency metrics alone will mislead. Track at least:
- Detection latency — time between a risk-relevant change and the firm acting on it. This is the metric that justifies the programme.
- Trigger precision — proportion of events that resulted in a rating change or action. Very low precision means noise; very high may mean under-triggering.
- Coverage — proportion of risk factors with a mapped trigger.
- Review volume — useful, but as a consequence rather than an objective.
Build the Trigger Set on Real Data
Continuous screening, structured ownership that generates change events, and behavioural baselines — with the trigger coverage map and audit record a supervisor will ask for.
