Perpetual KYC: The PII Re-Pull Vendor Guides Don’t Mention

Vendor pages describe perpetual KYC as continuous, real-time monitoring of the customer relationship. In operation, most perpetual KYC fires on an event: a sanctions designation, a material change, an adverse-media hit, a transaction-pattern shift. The gap between “continuous” and event-driven matters more under the Anti-Money Laundering Regulation (AMLR) Article 26 ongoing-monitoring obligation and FinCEN’s Anti-Money Laundering Act 2020 effectiveness pivot than the vendor cohort acknowledges. It matters more still under a question the SERP rarely poses: whether a reusable attestation can re-fire customer-side re-verification on an event without re-pulling the underlying personal data.

The “perpetual” label oversells what the architecture delivers

Perpetual KYC promises something the pKYC architecture does not literally deliver. The operational reality across the pKYC product cohort is closer to event-driven CDD refresh on a defined trigger set than anything continuous. The perpetual KYC label, also called continuous KYC, oversells the architecture.

Perpetual KYC fires on a signal: real-time sanctions screening feeds publish a designation, an adverse-media hit lands, transactions diverge, or a periodic refresh window expires. Between events pKYC waits. Wolfsberg’s March 2022 Guidance on Digital Customer Lifecycle Risk Management calls this a “targeted, disciplined approach to on-going due diligence by refreshing customer data on a trigger (rather than periodic) basis” (7). Perpetual KYC is shorthand for a faster refresh cycle, not literally continuous re-verification. Compliance teams reading vendor pages absorb the assumption that traditional KYC’s periodic review is replaced by something marketed as continuous monitoring — a system watching every customer at every moment. The risk picture changes at distinct points; the architectural question is what the compliance programme does there.

What event-driven KYC actually does in operation

An event-driven pKYC model is built around a trigger event set and an evaluation layer. Perpetual KYC’s trigger set defines what counts as a change in the customer risk picture: a sanctions feed delta, an adverse-media match, a registry update, a transaction-pattern shift outside the customer’s risk profile, or the Anti-Money Laundering Regulation (AMLR) Article 26(3) “circumstances change materially” formulation (1). When one fires, perpetual KYC schedules a CDD refresh narrowed to the trigger, keeping customer information current with the AMLR cadence.

Wolfsberg’s 2022 guidance describes pKYC as a trigger-based approach, framing the shift “from traditional periodic refresh cycles to a more effective trigger-based approach” (7). SERP-cohort vendors call the same shape event-driven — the wording diverges, the mechanism aligns. Perpetual KYC leans on automated screening: real-time sanctions feeds, real-time adverse-media feeds, real-time PEP refresh, behaviour analytics on transaction-pattern signals. Each supplies real-time risk signals to an evaluator deciding whether automated refresh fires.

Manual checks at a fixed 1-, 3- or 5-year cadence — Wolfsberg frames the practice as ripe for replacement — are the legacy baseline; an analyst opened the customer file on schedule whether anything had changed. Customer experience changes too: fewer routine re-verifications, more targeted requests on event. False positives are the hardest engineering constraint. Alerts from automated trigger detection require triage; tune the pKYC trigger set tightly and material changes are missed, loosely and false positives swamp review queues.

AMLR Article 26 and ongoing customer due diligence

EU Regulation 2024/1624 — AMLR — codifies the ongoing-monitoring obligation in Article 26 as the regulatory anchor for ongoing customer due diligence. Obliged entities “shall conduct ongoing monitoring of business relationships, including transactions undertaken by the customer throughout the course of a business relationship”, keeping transactions “consistent with the customer’s business activity and risk profile” (1). Article 26 is risk-based, not continuous: Article 26(2) sets the cadence every year for higher-risk customers under enhanced due diligence (EDD) measures and every five years otherwise; Article 26(3) requires a refresh “when circumstances change materially”; Article 26(5) instructs AMLA to issue ongoing-monitoring guidelines by 10 July 2026. AMLA’s draft Guidelines under Article 26(5), published 3 June 2026, set out “horizontal principles applicable to all obliged entities” (2); consultation closes 3 September 2026. None asks for genuinely continuous re-verification.

FATF Recommendation 10 — firms “should determine the extent of such measures using a risk-based approach (RBA)” — runs through every layer (6); JMLSG §5.7 (August 2025) requires the same basis (8); Basel d505 (July 2020) ties a sound KYC programme to “on-going monitoring of higher risk accounts” (9). For a closer look, see what AMLA actually means by ongoing customer due diligence. Regulators want risk-proportionate ongoing monitoring on AMLR’s 1-/5-year cadence and on material change; refreshing ultimate beneficial ownership on a registry delta is one representative data flow inside a periodic know your customer (KYC) review framework.

Verifyo issues attestations at verification time and refreshes on the fixed expiry cadence; it does not run continuous monitoring of customer transactions, nor verify physical addresses or Source-of-Funds. For the services we cover at Level 1 — identity-document verification, age attestation, sanctions / PEP / adverse-media / criminal-record screening at verification time — the verifier-private attestation removes the per-event PII re-pull a data-aggregation pKYC model requires.

What FinCEN’s effectiveness pivot asks financial institutions to do

The US-side anchor is the Anti-Money Laundering Act of 2020, Section 6101, amending 31 U.S.C. §5318(h) to require AML/CFT programmes to be “reasonably designed to assure and monitor compliance” with the Bank Secrecy Act on a risk-based basis (3). Section 6101(b) directed Treasury to “establish and make public priorities” — the regulatory lever for FinCEN to evaluate financial institutions’ programmes on effectiveness rather than calendar review.

FinCEN’s first operationalisation was the June 2021 AML/CFT National Priorities — corruption, cybercrime, terrorist financing, fraud, drug-trafficking, human trafficking, proliferation financing — which “aim to help covered entities assess their risks, tailor their AML programs, and prioritize their resources” (4). The Priorities reframe the financial crime question for financial institutions: do compliance teams allocate resources where elevated financial crime risk sits, or scatter them across a periodic review calendar? The 3 July 2024 NPRM proposes “explicitly require that AML/CFT programs be effective, risk-based, and reasonably designed” (5). The same NPRM frames the operational implication: “effective, risk-based” programmes enable “financial institutions to focus their resources consistent with their risk profiles”, directing attention toward higher-risk customers rather than uniform periodic review (5).

For compliance teams under the effectiveness standard, the supervisory test shifts from “did the calendar review fire on schedule” to “did the AML compliance programme catch what mattered”. The KYC process at financial institutions is evaluated against financial crime outcomes, not file-by-file cadence. Financial institutions designing AML programmes against the effectiveness standard allocate compliance resources by financial crime risk, not by review calendar. The risk-based approach the AML Act codifies binds; how the firm operationalises it against the regulatory standard is a programme-design choice the rule leaves open.

Where vendor explainers miss the architectural question

Read the SERP-cohort pKYC explainers — Moody’s, Fenergo, Quantexa, ComplyAdvantage, D&B — the pKYC framework is the same. The pKYC vendor pulls data from more sources, aggregates into a customer record, screens against more lists, re-runs analytics. Quantexa frames pKYC as “more continuous and event-driven” (11) without separating the “continuous” claim from event-driven reality. The pKYC software cohort defaults to the same data-aggregation pKYC architecture; pKYC providers converge on it.

That is one pKYC architecture, not the only one. The question pKYC vendors do not ask is what happens to underlying customer information each time perpetual KYC fires. Traditional KYC transferred customer documents to every receiving platform needing evidence of compliance. pKYC vendor tools inherit that assumption: when the trigger event fires, pKYC providers re-pull the same customer information, re-aggregate, re-screen, re-distribute. The pKYC verification process is faster, the refresh event-driven, the technology more sophisticated — yet the data flow looks structurally like the traditional KYC it replaces.

The architectural elements of a pKYC system, in the vendor cohort’s framing, are data sources, screening engines, analytics, case-management workflow. None answers the data-leakage question. For contrast on how the traditional KYC architecture transfers raw PII to every receiving platform, the architectural decision precedes the vendor selection. Refresh-frequency gains amortise the privacy cost across more events rather than removing it.

Verifier-private attestation: re-verification without re-pulling PII

A verifier-private attestation lets a receiving platform check that a customer satisfies a regulatory criterion without holding underlying personal data. The property aligns with the W3C Verifiable Credentials Data Model 2.0 (W3C Recommendation, 15 May 2025), describing “a three-party ecosystem for the exchange of these credentials composed of issuers, holders, and verifiers” (10). In the three-party issuer/holder/verifier ecosystem, the issuer attests to a fact, the holder holds the credential, the verifier checks it — the underlying data never crosses the verifier’s threshold.

At Verifyo, we implement this as a Zero-Knowledge KYC attestation: the receiving platform receives proof that the customer’s Level 1 verification status (identity, age, sanctions / PEP / adverse-media / criminal-record screening at verification time) is current, without seeing documents or results. Customer information stays with the issuer; the receiving platform sees only the KYC compliance status proof. When an event fires — a sanctions designation, an attestation expiry, a regulatory refresh — the proof is re-presented, not the data.

The enhanced security property follows from the architectural decision. A re-verification model re-pulling PII at every event multiplies the data-leakage surface proportional to event frequency; a verifier-private model leaves that surface flat. The KYC compliance check happens at the verifier’s threshold; the data security boundary holds. Polygon ID, Civic and zkMe implement the three-party model with different trade-offs — the architectural question separates the verifier-private cohort from data-aggregation pKYC implementations.

What this means for compliance teams designing past periodic review

Perpetual KYC delivers less than its name promises. The perpetual KYC label asks compliance teams to picture continuous re-verification; the operational shape is event-driven. The regulatory drivers — AMLR Article 26 with AMLA’s draft Guidelines under consultation through 3 September 2026, FinCEN’s AML Act 2020 effectiveness pivot, FATF Recommendation 10’s risk-based approach — do not ask for continuous re-verification. They ask for risk-proportionate ongoing monitoring, refreshed on material change, evaluated on outcomes, not calendar compliance. Traditional KYC’s recurring document transfer is the legacy past periodic reviews are moving from. Two advantages follow from the verifier-private answer: per-event PII re-pull goes away, and AML compliance status can be refreshed at any frequency without scaling data-handling exposure. The key components of a defensible pKYC architecture are not the data sources and screening engines — they are the issuer, the holder, the verifier, and the proof.

Sources

(1) European Parliament and Council. Regulation (EU) 2024/1624 — Anti-Money Laundering Regulation (AMLR), Article 26 — Ongoing monitoring of the business relationship and monitoring of transactions performed by customers. 31 May 2024. https://eur-lex.europa.eu/eli/reg/2024/1624/oj/eng

(2) Authority for Anti-Money Laundering and Countering the Financing of Terrorism (AMLA). Consultation Paper — Draft Guidelines on the ongoing monitoring of a business relationship under Article 26(5) of Regulation (EU) 2024/1624. 3 June 2026. https://www.amla.europa.eu/policy/public-consultations/consultation-draft-guidelines-ongoing-monitoring-business-relationship_en

(3) United States Congress. Anti-Money Laundering Act of 2020, Section 6101 — Strengthening the Bank Secrecy Act (Public Law 116-283, Division F). 1 January 2021. https://www.congress.gov/crs-product/R47255

(4) Financial Crimes Enforcement Network (FinCEN). Anti-Money Laundering / Countering the Financing of Terrorism National Priorities. 30 June 2021. https://www.fincen.gov/system/files/shared/AML_CFT%20Priorities%20(June%2030,%202021).pdf

(5) Financial Crimes Enforcement Network (FinCEN). Notice of Proposed Rulemaking — Anti-Money Laundering and Countering the Financing of Terrorism Programs. Federal Register, 3 July 2024. https://www.federalregister.gov/documents/2024/07/03/2024-14414/anti-money-laundering-and-countering-the-financing-of-terrorism-programs

(6) Financial Action Task Force (FATF). The FATF Recommendations — Recommendation 10 (Customer due diligence). Adopted February 2012; latest update October 2025. https://www.fatf-gafi.org/content/dam/fatf-gafi/recommendations/FATF%20Recommendations%202012.pdf.coredownload.inline.pdf

(7) Wolfsberg Group. Guidance on Digital Customer Lifecycle Risk Management. 29 March 2022. https://wolfsberg-group.org/resources/innovation/56

(8) Joint Money Laundering Steering Group (JMLSG). Prevention of money laundering / combating terrorist financing — Part I, Chapter 5, Section 5.7 (Monitoring customer activity). Updated August 2025. https://www.jmlsg.org.uk/wp-content/uploads/2025/09/JMLSG-Guidance-Part-I_June-2023-updated-Aug-2025.pdf

(9) Basel Committee on Banking Supervision (BCBS). Sound management of risks related to money laundering and financing of terrorism (BCBS d505, July 2020; BCBS 275 original guidance). Bank for International Settlements. https://www.bis.org/bcbs/publ/d505.htm

(10) World Wide Web Consortium (W3C). Verifiable Credentials Data Model v2.0. W3C Recommendation, 15 May 2025. https://www.w3.org/TR/vc-data-model-2.0/

(11) Quantexa. A Practical Guide to Perpetual KYC (pKYC). https://www.quantexa.com/resources/perpetual-kyc-guide/