Perpetual KYC: Why the EU's 2027 AML Regulation Makes Periodic Review an Architectural Liability

A customer onboarded as low-risk in January can become high-risk in March and stay flagged as low-risk until the next scheduled review, sometimes years later. This is not a detection failure. It is the designed behavior of a review cycle that checks customer risk on a calendar, not on an event.

Regulation (EU) 2024/1624, the AML Regulation (AMLR), applies directly across all EU member states from 10 July 2027. Unlike the directives it replaces, it requires no national transposition; the text is the law in every jurisdiction simultaneously. AMLR sits alongside the new Anti-Money Laundering Authority (AMLA, Regulation (EU) 2024/1620), which became operational on 1 July 2025 and supervises high-risk obliged entities directly. Both instruments share an assumption that periodic review architectures do not satisfy: customer risk is continuous, and the control framework must observe it continuously.

What the Calendar-Driven Model Actually Does

A periodic KYC review model assigns each customer a review interval, typically one to five years depending on risk tier, and re-verifies the customer profile when that interval elapses. Between reviews, the system does not look. It is not that the system fails to detect new sanctions exposure, an ownership change, or adverse media coverage; it is not designed to check for them until the scheduled date arrives.

This produces a specific failure mode: a sanctioned entity, a politically exposed person promoted into office, or a beneficial owner change can sit inside a financial institution's customer base, undetected by the institution's own controls, for the entire remaining length of the review interval. A five-year review tier on a customer who became material six months after onboarding leaves four and a half years of unmonitored exposure. Capgemini's 2026 financial crime compliance research frames this directly: early adopters of event-driven monitoring report removing 70 to 90 percent of the manual periodic review workload that this gap previously demanded, precisely because most of that workload was reviewing customers whose risk had not changed at all.

The inefficiency runs in both directions. A calendar-driven model spends investigation effort on customers whose risk profile is stable and unchanged, because the review date arrived regardless of whether anything happened. It spends no effort on customers whose risk changed the day after their last review, because nothing triggers a look until the next date arrives. The cost is high and the coverage is wrong at the same time.

The Global Baseline: FATF, Wolfsberg, and Examination Practice

The expectation that customer risk monitoring should be continuous is not new with AMLR. FATF Recommendation 10 has required "ongoing due diligence on the business relationship and scrutiny of transactions" since long before AMLR existed. The recommendation does not specify a review interval. It specifies a standard: transaction activity must stay consistent with what the institution knows about the customer, on an ongoing basis, not at the next scheduled checkpoint.

The Wolfsberg Group, whose correspondent banking due diligence guidance shapes practice across the world's largest banks, treats event-driven review as the baseline expectation for higher-risk relationships, not an enhancement layered on top of periodic review. A transaction spike, a sanctions hit, a new beneficial owner disclosure, or an adverse media alert is the trigger; the calendar is not. Under that framing, a calendar-only model does not meet the baseline for complex or elevated-risk segments, regardless of how short the interval is set.

UK supervisory practice shows what the gap looks like under examination. The FCA's 2022 Financial Crime Thematic Review of retail banks found that a number of firms had not updated customer risk profiles in years, despite running formally compliant periodic review schedules. The control gap was not a missed review. It was the review schedule itself: a risk profile can be technically current under a five-year cycle and still be years out of date relative to the customer's actual activity.

The Mechanism: Event-Driven Risk Re-Evaluation

An event-driven compliance architecture replaces the calendar trigger with a set of external and internal events that re-evaluate customer risk the moment they occur, rather than waiting for a scheduled date.

Event ingestion. The system subscribes to risk-relevant event streams: sanctions list publications (OFAC, EU, UN, UK consolidated lists), PEP database updates, adverse media feeds, corporate registry changes affecting beneficial ownership, and internal behavioral signals from transaction monitoring. Each event arrives as a normalized record: entity identifier, event type, source, timestamp, and a payload describing what changed.

Policy re-evaluation, not re-onboarding. A new sanctions hit on a customer does not require re-running the full onboarding flow. It requires re-evaluating the specific CDD policy dimensions affected by that event type against the customer's current risk profile. If the CDD policy model is versioned along jurisdiction, risk level, and check type, a sanctions event triggers only the sanctions-screening dimension of the policy, not document re-verification or address re-confirmation. This is the structural difference between perpetual KYC and "faster periodic reviews": the former re-checks what changed, the latter re-checks everything on a shorter clock.

Materiality routing. Not every event requires a human decision. A name-match against a watchlist that resolves to a different person through automated discounting can close without escalation. A confirmed sanctions hit, a material ownership change, or a risk-score movement past a defined threshold routes to a human reviewer with the triggering event, the prior risk assessment, and the delta between them already assembled. The system's job is to reduce the analyst's task from "investigate this customer from scratch" to "confirm or override this specific risk delta."

Continuous audit trail. Every event, every policy evaluation, and every routing decision is logged with the triggering event ID, the policy version applied, and the outcome. Under AMLR, the institution must be able to demonstrate not just that a customer was eventually reviewed, but that the control framework reacted to specific risk-relevant events within a defensible time window. A log that says "reviewed January 2027, next review January 2030" does not answer that question. A log that says "sanctions update received 14:32:07, policy v.12 applied, no material change, closed automatically" does.

Why "Faster Periodic Reviews" Is Not the Same Thing

A common shortcut is to shorten the review interval (annual instead of triennial, quarterly instead of annual) and call it modernization. This does not change the underlying architecture; it only increases its operating cost. The system still checks on a clock, still re-investigates customers whose risk has not moved, and still misses the gap between the event and the next scheduled date, just a smaller gap. Moody's framing of pKYC describes the same distinction: the shift is from periodic assessment refreshed more often to an always-on model where the trigger is the event itself, not the calendar.

Regulatory examiners increasingly test for this distinction directly. AMLA's direct supervisory mandate over high-risk entities means examination will probe whether a flagged event (a sanctions designation, an adverse media report) produced a documented, timestamped institutional response, not whether the customer happened to fall due for review around the same time. A shortened interval that, by coincidence, catches an event within its window is not evidence of a working control. It is evidence of luck.

A Common Misclassification: AML Monitoring Is Not Automatically "High-Risk AI"

Vendor material in this space frequently states that AML and KYC monitoring systems are classified as high-risk AI under the EU AI Act's Article 6 and Annex III. The European Commission's draft guidelines on Annex III classification, published 19 May 2026 and open for consultation until 23 June 2026, read the text differently. Annex III, point 5(b), covers AI systems that evaluate creditworthiness or establish a credit score. AML/CFT monitoring is governed by separate EU anti-money laundering legislation, and the Commission's draft reading places it outside point 5(b) unless the system's intended use also covers a creditworthiness or credit-scoring decision.

The distinction carries architectural weight, not just a labeling difference. An institution that shares model infrastructure between AML monitoring and credit decisioning, rather than keeping the two functions structurally separate, can pull its AML capability into AI Act high-risk scope through that shared infrastructure alone. Clean separation between the financial-crime function and the creditworthiness function is the practical way to avoid an unintended classification, not a compliance footnote.

This does not relax the AMLR, FATF Recommendation 10, or Wolfsberg obligations described above. Event-driven AML monitoring still has to work, still has to be auditable, and still has to react to events rather than calendars. What changes is the claimed legal basis for it: AMLR, AMLA, and FATF Recommendation 10 drive the requirement. The AI Act's high-risk regime, as currently drafted, generally does not.

Trade-offs

Event-driven monitoring is not without cost, and the costs are structural, not incidental.

Alert volume. Subscribing to more event sources increases the raw number of signals the system must triage. Rule-based transaction monitoring already operates at the upper bound of this problem: PwC-cited industry analysis, referenced consistently since 2018, places false positive rates for traditional rules-based screening at 90 to 95 percent of generated alerts. Event-driven KYC that adds sources without a materiality layer reproduces that ratio in a different control. The materiality layer is not optional; without it, event-driven monitoring trades one form of inefficiency for another.

Data source dependency. The system's coverage is bounded by the event sources it subscribes to. A sanctions list provider with a four-hour publication lag, or an adverse media feed that does not cover a relevant regional language, creates a blind spot that looks identical to a working control from the inside. Event-driven architecture shifts risk from "we didn't look" to "we looked, but our source didn't tell us," which is a different audit conversation but not necessarily a smaller one.

Migration cost from a fiat-only data model. Institutions whose CDD records are structured around a single review date per customer, rather than a continuously updated risk state with an event history, cannot bolt event-driven monitoring onto the existing schema. The customer record itself needs to become an entity with a risk timeline, not a row with a next-review-date column. This is a data model change, not a feature flag.

Fernel Context

Fernel's compliance engine treats AML screening as a continuous process rather than a point-in-time check: screening results are subject to automatic re-screening as sanctions, PEP, and adverse media sources update, without a scheduled review date driving the trigger. CDD policies are versioned records spanning jurisdiction, risk level, and check type, so a risk-relevant event resolves to the specific policy dimension it affects rather than triggering full re-verification. Risk levels (low, medium, high, prohibited) escalate automatically when an indicator crosses a defined threshold, and every screening result, policy evaluation, and escalation is recorded in the same hash-chained audit trail that covers the rest of the compliance workflow. The architecture does not eliminate the need for a human reviewer on material changes; it eliminates the gap between when a change occurs and when the system notices.

---

Read more: Compliance Infrastructure | Automating Customer Due Diligence | Synthetic Identity Fraud and the Onboarding Stack

---

Sources:

• Regulation (EU) 2024/1624 (AMLR), applicable from 10 July 2027 across all EU member states without national transposition
• Regulation (EU) 2024/1620, establishing the Authority for Anti-Money Laundering and Countering the Financing of Terrorism (AMLA), applicable from 1 July 2025
• Capgemini, "Reimagining KYC: From legacy friction to the pKYC triad" (2026): 70-90% reduction in periodic review workload among early pKYC adopters; up to 40% false positive reduction; 40-60% faster onboarding; 70% smaller case backlogs
• Moody's, "Perpetual KYC" framework overview: distinction between calendar-based refresh and event-driven, always-on risk monitoring
• FATF Recommendation 10 (Customer Due Diligence), International Standards on Combating Money Laundering and the Financing of Terrorism and Proliferation, last updated 2026
• Wolfsberg Group, Correspondent Banking Due Diligence guidance: event-driven review as the baseline expectation for higher-risk relationships
• FCA, 2022 Financial Crime Thematic Review of retail banks (UK)
• European Commission, draft guidelines on the classification of high-risk AI systems under Article 6 and Annex III of the EU AI Act, published 19 May 2026 (consultation period to 23 June 2026); point 5(b) scope and the creditworthiness/credit-scoring linkage test
• PwC-cited analysis of false positive rates in rules-based transaction monitoring (90-95% range), referenced across industry research since 2018