A customer file that is only refreshed every one, three or five years is wrong for most of the time in between, and the gaps are where ownership changes, sanctions designations, mule activity and account takeovers go unnoticed. Perpetual KYC (pKYC), also called continuous, dynamic or event driven KYC, replaces calendar driven refreshes with reviews that start when something about the customer actually changes. This guide covers the trigger catalogue, the data sources that feed it, how the customer risk rating should move when a trigger fires, the governance a regulator will expect to see, and how to migrate from periodic review without opening a gap. It is written for financial crime operations leads, KYC and AML technology owners and the executives who sign off the programme. Onboarding proofing is covered in the Identity Proofing and KYC Guide and is not repeated here.
Key takeaways
- The law already asks for event driven review. UK Money Laundering Regulations 2017 regulation 27(8)(b) requires CDD on an existing customer when relevant circumstances change, and FinCEN's 2016 CDD rule describes the US updating duty as event driven, arising from normal monitoring.
- pKYC does not abolish periodic review. Rules still expect reviews of existing records, particularly for higher risk customers, so most programmes run a hybrid: triggers for everyone, a backstop review date for the riskiest.
- Triggers are only as good as the data behind them. Registry feeds, screening deltas, transaction monitoring outcomes and digital identity signals each need an owner, a latency target and a test.
- The risk rating must move, and be explainable. Every trigger should map to a defined effect on the customer risk rating and a defined review depth, recorded so an examiner can replay why a score changed.
- Governance is what regulators test. A written trigger catalogue, coverage metrics, backlog ageing and evidence that alerts were actioned matter more than the vendor or the model.
What perpetual KYC changes
Traditional KYC refresh works on a schedule: high risk customers every year, medium every two or three, low every five or so, with a large outreach team chasing documents whether or not anything has changed. pKYC keeps the same obligations but changes the control that starts a review. The customer record is linked to data sources that report change, and a review starts when a change is material to risk. Analysts spend their time on customers whose risk has moved, and low risk customers whose circumstances have not changed are not asked for the same passport again.
| Dimension | Periodic refresh | Perpetual (event driven) KYC |
|---|---|---|
| What starts a review | A date in the customer record | A trigger from a monitored data source, plus a backstop date for higher risk |
| Freshness of the file | Degrades steadily between reviews | Updated close to the moment a change is detected |
| Customer outreach | Bulk, often for unchanged information | Targeted at the specific attribute that changed |
| Analyst workload | Peaks around review cycles and backlogs | Continuous queue, sized by trigger volume |
| Main failure mode | Overdue reviews and stale files | Silent data feeds and untested trigger logic |
| What an examiner asks for | Overdue review counts | Trigger catalogue, feed coverage, alert to action evidence |
What regulators actually require
No major regime mandates "perpetual KYC" by name. What they require is ongoing monitoring and up to date customer information, applied on a risk basis, which an event driven model can meet if it is designed and evidenced properly. The table summarises the provisions that most programmes map to.
| Regime | Provision | What it requires |
|---|---|---|
| UK MLRs 2017 | Reg 27(8) and 27(9) | Apply CDD to existing customers at appropriate times on a risk based approach and when the firm becomes aware that relevant circumstances have changed. Timing must consider indications that the identity of the customer or beneficial owner has changed, transactions inconsistent with what the firm knows, a change in the purpose or intended nature of the relationship, and anything else affecting ML or TF risk. Reg 27(8)(za) adds review when the firm has a legal duty in the calendar year to contact the customer about beneficial ownership information. |
| UK MLRs 2017 | Reg 28(11) and 28(12) | Ongoing monitoring: scrutiny of transactions (including source of funds where necessary) for consistency with the customer's business and risk profile, and reviews of existing records to keep CDD documents and information up to date. The extent of measures must reflect the firm's risk assessment. |
| United States (FinCEN CDD rule) | 31 CFR 1020.210(a)(2)(v)(B) | Ongoing monitoring to identify and report suspicious transactions and, on a risk basis, to maintain and update customer information, including beneficial ownership of legal entity customers. The 2016 final rule preamble states the updating requirement is event driven and occurs as a result of normal monitoring, not a categorical periodic refresh. |
| Singapore (MAS Notice 626) | Paras 6.19 to 6.26, 8.3 | Monitor business relations on an ongoing basis, scrutinise transactions against the customer profile, and keep CDD data relevant and up to date by reviewing existing CDD, particularly for higher risk categories. No fixed interval is set. PEP relationships need enhanced monitoring. |
| European Union (AMLR, Regulation (EU) 2024/1624) | Article 26; recital 69 | The single rulebook applies from 10 July 2027. Article 26 requires ongoing monitoring of the relationship and its transactions and requires customer information to be kept up to date, with the period between updates set by risk but never longer than 1 year for higher risk customers under enhanced measures and 5 years for all other customers (Article 26(2)). Recital 69 adds that reviews should also be triggered by changes in the customer's relevant circumstances. Article 26(5) required AMLA to issue guidelines on ongoing monitoring by 10 July 2026. See the EU AML Regulation and AMLA Guide. |
Two consequences follow. First, an event driven design satisfies the UK and US texts directly, because both name changed circumstances as the trigger. Second, "particularly for higher risk categories" language in the UK and Singapore texts, mean a backstop review date for high risk and PEP customers remains prudent even in a mature pKYC programme. In the EU it is mandatory: from 10 July 2027 AMLR Article 26(2) caps the gap between updates at 1 year for higher risk customers and 5 years for everyone else, so triggers supplement those maximum dates rather than replace them. For the underlying CDD, EDD and PEP measures see the CDD, EDD, PEP and sanctions screening guide.
Building the trigger catalogue
The trigger catalogue is the core artefact of a pKYC programme. Each entry names the event, the source that detects it, the customer segments it applies to, the effect on the risk rating and the review depth. Start from the four factors in MLR regulation 27(9), because they are a regulator's own list, then add product and channel specific events.
| Trigger | Typical source | Default response |
|---|---|---|
| Change of beneficial owner, director or controller | Company registry feed, KYB data provider, customer notification | Re-verify the new owner, rescreen, refresh ownership structure; full review if the new owner is a PEP or in a higher risk jurisdiction |
| New sanctions, PEP or adverse media match | Screening delta run against list updates | Disposition the match first; confirmed match raises the rating and starts EDD or a freeze process |
| Transactions inconsistent with the profile | Transaction monitoring alert closed as unusual but not suspicious, or a SAR decision | Refresh expected activity and source of funds; SAR filings always force a relationship review |
| Change in purpose or nature of the relationship | New product, new business line, change of SIC or industry code | Re-run the customer risk assessment with the new product risk |
| Change of residence, nationality or operating jurisdiction | Address change, new payment corridors, IP or device geography | Rescreen and re-rate for geographic risk |
| Identity or contact change | Change of name, email, phone or registered device | Step-up authentication; review if paired with other risk signals |
| Document expiry | ID document expiry date held on file | Request a new document only where the rules or your risk policy require a current one |
| Dormant account reactivated | Core banking activity flags | Confirm identity and expected activity before large outflows |
| Law enforcement request or production order | Financial crime intelligence unit | Relationship review by a senior analyst |
- Materiality thresholds: not every change is material. A street address move inside the same city is not the same as a move to a high risk jurisdiction. Define thresholds per trigger and record why.
- Combining weak signals: a new phone number alone may not justify a review; a new phone number, a new device and a payee added within the same day is an account takeover pattern. Correlate signals before raising work. See the Account Takeover Prevention Guide.
- Segment specific triggers: corporate customers need registry and ownership triggers; retail customers lean on transaction, device and screening triggers; correspondent relationships need jurisdiction and regulatory action triggers.
Data sources and feed engineering
pKYC moves the risk from analysts to data plumbing. A trigger that never fires because a feed broke looks identical to a customer whose circumstances never changed. Treat every feed as a control with an owner.
| Source | Trigger it supports | Engineering concerns |
|---|---|---|
| Company registries and KYB providers | Ownership, officer, status and filing changes | Entity matching to the right registered company, coverage gaps by country, update latency |
| Sanctions, PEP and adverse media lists | New designations and newly relevant media | Delta screening of the whole book after each list update, not just new customers; list version logged per run |
| Transaction monitoring | Activity inconsistent with profile | Feeding alert outcomes back into the profile, not only to the case system |
| Core banking and CRM | Product changes, address and contact changes, dormancy | Event publication on change, rather than nightly full extracts that hide what changed |
| Digital identity and fraud signals | Device, SIM swap, credential and behavioural anomalies | Privacy and purpose limitation, false positive rates, retention |
| Customer self service | Customer declared changes | Verification of declared changes before they lower risk |
Two engineering rules prevent most silent failures. Log the last successful update per feed and alert when it exceeds a latency target, and run synthetic test records through each feed on a schedule (a test company with a known director change, a test name added to a test list) to prove end to end that the trigger fires and lands in a queue. For corporate data quality see the KYB Guide.
Updating the customer risk rating
When a trigger fires, the customer risk rating (CRR) is recalculated, not just annotated. Regulators expect the CRR to drive the depth of ongoing monitoring under MLR regulation 28(12), so a stale CRR means monitoring calibrated to the wrong customer.
- Recalculate automatically: rerun the CRR model on the new attribute values as soon as the trigger is accepted, and store the before and after scores with the triggering event.
- Apply override rules: confirmed sanctions exposure, a PEP determination or a SAR filing should force a minimum rating regardless of the model score.
- Set review depth by score movement: no change in band means a light touch update; one band up means a targeted review of the changed attribute; two bands up or a forced override means full review with EDD where required.
- Allow downgrades only with evidence: a rating should fall only after a human has verified the change that justifies it, and the reason should be recorded.
- Recalibrate monitoring: push the new rating to transaction monitoring thresholds and screening frequency so the next alert reflects the new risk.
Explainability is the test. For any customer, an examiner should be able to see every rating change, the trigger behind it, the data at the time and who approved it. Machine learning scores can contribute, but the factors and weights that moved the rating must be retrievable.
Governance and operating model
- Ownership: the MLRO or BSA officer owns the trigger catalogue and the risk appetite behind the thresholds; data owners own feed health; operations owns queue service levels.
- Change control: adding, removing or retuning a trigger goes through the same approval as a transaction monitoring rule change, with testing evidence and a record of the expected impact on volumes.
- Service levels: define time from trigger to review start and from review start to completion by severity. Sanctions triggers are measured in hours, ownership changes in days.
- Backstop reviews: keep a maximum interval for high risk and PEP relationships even when no trigger fires, and document why lower risk segments have no fixed interval if you choose that.
- Customer outreach: ask only for what changed, through authenticated channels. Requests for documents through unauthenticated email train customers to respond to phishing.
- Independent testing: internal audit or a second line function samples customers with no triggers to confirm that no change was missed.
Migrating from periodic review
- Baseline the book: measure current file completeness, overdue reviews and data quality by segment. pKYC on top of incomplete files only automates the gaps.
- Remediate first, then switch: bring each segment to a known good baseline before removing its fixed review date.
- Run in parallel: pilot one segment, usually low risk retail, with triggers live and periodic review still scheduled. Compare what triggers found against what the periodic reviews found.
- Retire dates segment by segment: remove fixed dates only where the parallel run shows triggers catch the material changes, and record the decision for the regulator. For EU customers keep a date no later than the AMLR Article 26(2) maximum, even where triggers perform well.
- Extend to higher risk segments: add triggers for corporate, high risk and PEP customers but keep their backstop reviews.
- Rollback plan: if a feed fails or a trigger is found to miss changes, restore the periodic date for the affected segment until the fault is fixed and tested.
Small versus large firms: a small firm with a few thousand customers can run a light version with screening deltas, registry alerts for corporate customers and transaction monitoring feedback, plus annual high risk reviews. A large bank needs event streaming from core systems, entity resolution across business lines and a dedicated feed operations function. Neither should claim pKYC until feed health is measured.
Detection and measurement
- Feed coverage: percentage of customers linked to each relevant source (for example, corporate customers matched to a registry record).
- Feed freshness: time since last successful update per feed, against a latency target.
- Trigger to action time: median and 95th percentile time from trigger to completed review, by severity.
- Backlog ageing: open trigger reviews past their service level, split by risk band.
- Missed change rate: material changes found by backstop reviews, audits or examinations that no trigger caught. This is the most honest measure of whether pKYC works.
- Outreach reduction: customer document requests per thousand customers before and after, a business benefit that should not come at the expense of the missed change rate.
Where identity fits
pKYC and account security share signals. A SIM swap, a new device enrolment, a password reset followed by a contact detail change or a burst of new payees are both fraud indicators and KYC triggers, because the person operating the account may no longer be the verified customer. Route these events to both teams. Equally, a KYC review that discovers changed control of an account should feed back into authentication policy, for example forcing re-enrolment of authenticators. Synthetic identities often pass onboarding and reveal themselves only through later behaviour, which is where ongoing monitoring earns its keep. See the Synthetic Identity Fraud Guide and the Money Mule Detection Guide.
Common failure patterns
- Removing review dates before feeds are proven: the book goes quiet because nothing is watching, not because nothing changed.
- Screening only new customers: list updates are not run against the existing book, so a customer designated last week is found at the next periodic review, if ever.
- Triggers that annotate but do not re-rate: analysts add a note to the file while the customer risk rating and monitoring thresholds stay at the old level.
- Alert outcomes that stay in the case system: transaction monitoring closes an alert as unusual but explained, and the expected activity profile is never updated, so the same alert fires again next month.
- Too many low value triggers: every address or phone change creates a case, the queue floods, and material triggers wait behind trivial ones. Tune materiality and correlate signals.
- Undocumented thresholds: the firm cannot show an examiner why a trigger was set where it was, or what testing supported a change.
Practitioner checklist
- Map your regime's ongoing monitoring provisions (for example MLR 27(8), 27(9), 28(11) or 31 CFR 1020.210) to a written trigger catalogue.
- Give every trigger a source, owner, materiality threshold, risk rating effect and review depth.
- Run delta screening of the whole book after every sanctions and PEP list update, and log the list version.
- Instrument feed freshness with alerts, and push synthetic test records through each feed on a schedule.
- Recalculate the customer risk rating on every accepted trigger, store before and after scores, and allow downgrades only with verified evidence.
- Keep backstop review intervals for high risk and PEP customers, documented and approved by the MLRO.
- Pilot one segment in parallel with periodic review, compare results, and retire fixed dates only where triggers proved equivalent.
- Report feed coverage, trigger to action time, backlog ageing and missed change rate to the financial crime committee.
- Route account security signals such as SIM swap and authenticator changes to both fraud and KYC queues.
Standards and references
- legislation.gov.uk: Money Laundering Regulations 2017, regulation 27 (customer due diligence)
- legislation.gov.uk: Money Laundering Regulations 2017, regulation 28 (ongoing monitoring)
- Code of Federal Regulations: 31 CFR 1020.210, AML programme requirements for banks
- FinCEN: Customer Due Diligence Requirements for Financial Institutions, final rule (Federal Register, 11 May 2016)
- Monetary Authority of Singapore: Notice 626 on prevention of money laundering and countering the financing of terrorism (banks)
- EUR-Lex: Regulation (EU) 2024/1624 on the prevention of the use of the financial system for money laundering or terrorist financing
- JMLSG: Current guidance for the UK financial sector
Related NHI Mgmt Group resources: Identity Proofing and KYC Guide · CDD, EDD, PEP and sanctions screening · AML programme and transaction monitoring · KYB Guide · EU AML Regulation and AMLA Guide. This guide summarises regulatory requirements and is not legal advice.