Periodic and Event-Driven Reviews

A customer file is not finished when onboarding is approved. The bank has only established an evidence-based view of the customer at a point in time. After that, the customer may change ownership, enter new markets, add products, alter payment corridors, appoint new directors, become politically exposed, experience adverse publicity or simply start behaving in a way that no longer fits the bank's understanding of the relationship. The practical purpose of ongoing customer due diligence is therefore to keep the bank's understanding sufficiently current for later controls and decisions to remain reliable.

Periodic and event-driven reviews are two operating disciplines for doing that work. A periodic review is scheduled according to the institution's applicable legal framework, risk methodology and internal policy. An event-driven review begins because new information may be relevant to the customer's risk or to the adequacy of existing CDD. Neither is a universal global timetable. FATF Recommendation 10 establishes the broader international expectation that financial institutions conduct ongoing due diligence and keep CDD information up to date and relevant, particularly for higher-risk customers. How a jurisdiction translates that expectation into mandatory review frequencies, event triggers, enhanced measures or recordkeeping differs materially.

That distinction matters. In the United States, current FFIEC and FinCEN material explicitly says there is no categorical requirement to update customer information on a continuous or periodic schedule. The US obligation is risk based and normally arises through ongoing monitoring when information relevant to the customer's risk becomes known; banks may also adopt periodic reviews under their own policies. Australia takes a different route under its reformed AML/CTF framework effective from 31 March 2026: AUSTRAC describes periodic review of KYC information at a frequency appropriate to ML/TF risk and review when specified events or doubts arise. In the United Kingdom, ongoing monitoring is risk-sensitive and includes keeping CDD information current, while firms design practical review arrangements under the Money Laundering Regulations and relevant guidance. In the European Union, firms must continue to follow the law currently applicable to them while preparing for Regulation (EU) 2024/1624, which generally applies from 10 July 2027. A global bank therefore needs jurisdiction mapping, not one copied review calendar presented as universal law.

This chapter treats review as a controlled decision process rather than an administrative refresh. The reviewer asks four questions. What has changed? Is the change reliable and material? Does it alter what the bank understands about the customer or the relationship? What action follows under the relevant AML/CFT, sanctions, fraud, product and relationship-governance rules? A good review can end with no change, a targeted update, a revised risk profile, enhanced due diligence, a monitoring adjustment, escalation, reporting consideration, relationship restriction or a separate sanctions decision. The evidence must explain why.

Two complementary review disciplines: scheduled review and event-driven review converge on a scoped evidence assessment, while urgent sanctions or fraud controls remain separate decision paths.

The mental model: maintain the customer picture, not the paperwork

The easiest way to understand ongoing review is to imagine the bank maintaining a living customer picture. That picture contains identity, beneficial ownership and control, purpose of the relationship, expected products, expected transaction behaviour, geographic exposure, sources of funds or wealth where relevant, PEP or other status, connected parties and the risk factors used by the bank's methodology. Each element has an evidence source and an effective date. Some facts change rarely; others can change overnight.

A passport expiring does not necessarily mean the person has changed identity. A company filing a new director may be important or routine depending on the role and control implications. A tenfold rise in turnover may be consistent with a documented acquisition, or it may show that the onboarding profile is obsolete. A sanctions-list update can require immediate sanctions action even before the KYC team completes any customer review. A suspicious-activity alert can reveal new facts that justify customer reassessment, but the existence of an alert does not automatically mean the customer's risk rating must increase or that a suspicious report must be filed. The control architecture must preserve these distinctions.

A strong review programme therefore manages three related but separate things: information currency, risk reassessment, and downstream decisioning. Information currency asks whether the factual record is still reliable. Risk reassessment asks whether new facts alter the institution's view of ML/TF or related financial-crime risk. Downstream decisioning applies the law, policy and risk appetite relevant to the resulting issue. Collapsing all three into a single “KYC refresh” status hides important reasoning and creates operational errors.

What FATF actually requires

FATF Recommendation 10 is the global starting point, not a global operating manual. Its ongoing-due-diligence expectation has two core elements. Financial institutions should scrutinise transactions through the relationship so that activity is consistent with their knowledge of the customer, the customer's business and risk profile, including source of funds where necessary. They should also ensure that CDD documents, data and information remain up to date and relevant by reviewing existing records, particularly for higher-risk categories.

FATF does not prescribe one universal review frequency such as annual for high risk, three-yearly for medium risk and five-yearly for low risk. Many institutions use tiered schedules resembling that pattern, and some jurisdictions or supervisors may expect or require particular approaches, but the numbers must come from the applicable local framework and the bank's approved policy. Teaching an internal practice as a FATF rule creates a legal error and makes global implementation harder.

The risk-based approach also means review depth should be proportionate. A stable customer whose facts remain reliable may not need the same evidence refresh as a complex international group that has restructured twice, changed beneficial owners and opened new trade corridors. Conversely, “low risk” is not a licence to ignore material changes. A low-risk customer can experience an event that immediately invalidates the assumptions supporting simplified treatment.

Periodic review: a scheduled control, not a guaranteed legal formula

Periodic review gives the bank a deliberate opportunity to step outside day-to-day transaction processing and ask whether the relationship still makes sense as a whole. It is particularly useful as a backstop for changes that individual trigger rules may not catch. A company can drift from one business model to another through many small changes, none of which crosses an event threshold. A scheduled review can reveal the cumulative transformation.

The bank should define which populations are subject to scheduled review, how the interval is determined, what scope applies, what evidence is required and how exceptions are governed. Those choices may depend on customer risk, product complexity, legal entity type, geography, regulatory requirements, data quality, history of change and the availability of reliable continuous monitoring. The policy should also explain when a scheduled review can be narrowed because reliable current information is already available from trusted sources, and when the reviewer must broaden it because facts have become uncertain.

A periodic review should not mean asking the customer to resubmit every onboarding document regardless of relevance. Reverification should be driven by the applicable rules and by whether existing evidence remains adequate and reliable. Current AUSTRAC guidance, for example, explicitly notes that an expired identity document does not by itself change a person's identity or ML/TF risk and does not automatically require collection and reverification of that document. US FinCEN guidance similarly makes clear that routine periodic review is not, by itself, a trigger to recollect beneficial ownership information absent risk-based concerns. These jurisdiction-specific examples illustrate the same operational lesson: review the risk and evidence, not the date stamp alone.

Event-driven review: respond when the relationship changes

Event-driven review starts with new information. The source may be the customer, a registry, a screening platform, relationship management, transaction monitoring, fraud operations, adverse-media monitoring, a payment investigation, a law-enforcement request, a product team or another legal entity within the group. The trigger should create a review only when the information could matter to the customer picture, and the review scope should match the significance of the change.

Useful trigger families include ownership or control changes; changes to directors or authorised persons; new or changed PEP information; material changes to business activity, turnover, products, channels or geography; transaction behaviour inconsistent with the stated purpose of the relationship; credible adverse information; unexplained dormant-account reactivation; repeated monitoring alerts that reveal a changed pattern; material changes in source of funds or source of wealth; and information casting doubt on the adequacy or veracity of existing CDD.

A trigger catalogue is not a list of automatic outcomes. A registry update showing a new director may require only verification and record update. A new beneficial owner may require identity verification, screening, risk reassessment and potentially EDD. A transaction-monitoring alert may be closed as expected activity after investigation and therefore create no change to the customer profile. The system needs a materiality step between event detection and full review so that analysts do not receive every data change as if it were a financial-crime incident.

Trigger taxonomy showing customer, ownership, behavioural, external and connected-party changes feeding a materiality assessment before the bank selects an appropriate review scope.

Trigger quality: provenance, materiality and deduplication

A bank should know why a trigger fired and which source produced it. “Customer data changed” is not sufficient audit evidence. The event record should identify the changed field, old value, new value, source system, source document or external feed, effective date where known, detection time and any entity-resolution logic used to link the event to the customer.

Materiality rules then determine whether the event warrants automated update, analyst confirmation, targeted review or comprehensive reassessment. The bank should avoid pseudo-precision. A single fixed percentage change in turnover cannot determine materiality across every customer type. Materiality can depend on the relationship between the change and the original risk assumptions. A modest change in a controlling shareholder may matter more than a large change in ordinary turnover.

Deduplication is equally important. One corporate acquisition can produce a registry update, new beneficial-owner data, adverse-media hits, payment-pattern changes and relationship-manager notifications. If each creates a separate case, the bank fragments one risk story into multiple queues. A correlation layer should associate related events to the same customer and, where possible, the same underlying change so that one reviewer sees the combined evidence.

Review scope: targeted refresh or full reassessment

A review should have a defined scope before the analyst starts collecting evidence. Three broad patterns are useful, although names vary by institution.

A targeted refresh addresses a narrow change whose implications are understood. For example, a corporate customer changes registered address without any ownership, business or geographic-risk change. The reviewer verifies the new address, records the source and checks whether the change affects any linked controls.

A risk reassessment is appropriate when new information can change the customer's risk profile. A new beneficial owner, entry into a higher-risk market, material product expansion, new PEP exposure or sustained behaviour inconsistent with the existing profile may require reconsideration of several risk factors and an update to monitoring or EDD.

A comprehensive review is appropriate when the bank can no longer rely on the existing customer picture or where policy or law requires a broader reassessment. Examples include complex restructuring, repeated material inconsistencies, significant remediation of historic CDD weaknesses or a relationship whose accumulated changes make targeted updates unreliable.

The system should capture why a scope was selected and allow controlled expansion when the reviewer discovers new facts. It should also prevent analysts from marking a review complete if mandatory tasks for that scope remain unresolved.

Separate KYC review from sanctions interdiction

One of the most important decision boundaries is between customer review and sanctions control. A newly designated person, or information showing that a customer may be owned or controlled by a designated person, can require immediate action under the sanctions law applicable to the bank, transaction or asset. The bank may need to block, freeze, reject, restrict or report before a KYC review is complete. The exact action varies by jurisdiction and sanctions regime.

The customer review can still be important. It may establish whether the listed person is the same individual, whether ownership or control reaches the customer, whether other connected entities are affected and whether the relationship risk has changed. But a review workflow must never become a waiting room that delays a legally required sanctions disposition. Sanctions matching, legal applicability and asset-control decisions should retain their own urgent path, with the review receiving the resulting verified facts.

The same principle applies to fraud. If account-takeover controls need to restrict access immediately, the bank should not wait for a customer-risk review. After containment, the event may provide information relevant to the customer's profile. Controls cooperate; they do not become one undifferentiated queue.

Separate KYC review from suspicious-reporting decisions

An event-driven review can uncover suspicious activity, but customer risk and suspicion are different questions. A customer can be high risk without generating reportable suspicion, and a previously low-risk customer can conduct activity that meets the local reporting threshold. The reviewer should escalate facts to the investigation or MLRO process defined by the relevant jurisdiction without assuming that a risk-tier change answers the reporting question.

This boundary also protects confidentiality. Where suspicious reporting or an investigation is in progress, the KYC team may need access to selected facts without exposing restricted case information more broadly than necessary. Customer contact during a review should be assessed against local tipping-off or prejudicing-an-investigation rules where applicable. The workflow should therefore support restricted data, need-to-know permissions and controlled customer-questioning strategies.

How review fits the customer lifecycle

At onboarding, the bank establishes the original customer picture and records assumptions that future review will test. During servicing, transaction monitoring, screening, relationship management and external data feeds provide signals. Product changes, credit events, corporate actions and customer service interactions can also reveal material facts. At review, the bank compares the new evidence with the existing profile. After review, the outcome must propagate to the systems that rely on it.

That propagation is often where otherwise good review programmes fail. A reviewer can correctly identify a new high-risk geography while the transaction-monitoring engine continues using the old geography because the risk platform, customer master and monitoring platform synchronise overnight or not at all. A beneficial-owner change can be updated in KYC but not passed to screening. A risk-tier change can be stored without an effective date, making later investigators unable to reconstruct which controls should have applied when a transaction occurred.

For architects and BAs, the review is therefore a data lifecycle, not merely a case workflow. Important attributes include customer identifier, legal-entity identifier, review type, trigger type, trigger source, trigger time, review scope, evidence source, evidence date, changed attributes, old and new values, analyst decision, reason code, risk-profile version, effective date, approval where required, downstream systems notified and acknowledgement status. Historical versions should remain reconstructable.

Perpetual KYC: useful architecture, not a magic product

“Perpetual KYC” or “continuous KYC” usually describes an operating model in which reliable changes are detected and assessed between scheduled reviews so that the customer picture can be refreshed closer to the event. It is not a separate global regulatory obligation and it does not eliminate human judgement. It can reduce reliance on large calendar-driven refresh exercises where data quality and trigger coverage are strong.

A workable architecture combines source systems, external data, change detection, entity resolution, materiality rules, workflow, evidence storage and downstream synchronisation. Automation is most useful for deterministic tasks: detecting a registry change, comparing fields, matching identifiers, routing a case, checking whether required evidence is present or applying a documented low-risk update rule. Machine learning may be used by some institutions for prioritisation or anomaly detection, but it is not required and should not replace explainable control logic where legal or customer-impact decisions demand traceability.

Perpetual models need fallback design. If a registry feed is unavailable for two days, the system should know that coverage is degraded rather than silently treating “no event” as “no change.” If entity resolution confidence is low, the event may need manual confirmation. If a downstream system rejects an updated risk profile, the case cannot be considered operationally complete merely because the KYC repository saved the change.

Backlog is a risk condition, not just an operations metric

Review programmes inevitably create queues. The control problem begins when overdue work is hidden, prioritised only by age or treated as a throughput issue without considering customer risk and trigger urgency. A transparent backlog view should show the whole population, including overdue scheduled reviews, unresolved event-driven reviews, deferred cases and cases waiting for customer information, quality remediation or specialist advice.

Ageing should be combined with risk. A one-day-old event involving a material ownership change may require more urgent handling than a lower-risk scheduled review overdue by a modest period. A sanctions-related event may leave the review queue entirely for immediate sanctions handling. A suspected fraud event may already be under restriction. Backlog governance therefore needs priority logic, escalation rules and clearly documented exceptions.

Deferrals require their own control. A relationship manager should not be able to postpone an uncomfortable review repeatedly because the customer is commercially important. Where policy permits deferral, the system should capture reason, approver, expiry date, compensating controls and whether customer activity can continue unchanged. Serial deferrals and concentrated deferral patterns should appear in management information.

Backlog control showing full inventory, risk-and-urgency prioritisation, ageing and escalation, controlled deferral, surge actions and transparent governance.

Customer contact and evidence collection

Review requests can create unnecessary friction when the bank asks for information it already holds, requests the same document through multiple channels or gives the customer no explanation of why a routine update is needed. Good design reuses reliable information, asks only for what is necessary for the selected scope and distinguishes a request to confirm information from a request to reverify it.

Digital self-service can help customers confirm addresses, business details, expected activity and ownership changes, but the bank should not treat customer assertion as verification when independent verification is required. Corporate registry data, reliable identity sources, company documents, audited accounts, contracts, tax or licensing records and other evidence may be appropriate depending on the risk and jurisdiction. The reviewer should understand the evidential purpose of each item. More documents do not automatically produce better due diligence.

Where the customer does not respond, the next step depends on why the information is needed, the legal framework and the bank's policy. A missing convenience field is different from inability to complete required CDD. Escalation can include reminders, channel restrictions, enhanced monitoring, refusal of a new product, relationship restriction or exit, but the bank should avoid mechanically de-risking customers where proportionate measures can manage the risk and no legal prohibition applies.

Review outcomes and downstream controls

A review should end with an explicit outcome rather than a generic “complete” status. Typical outcomes include no material change; information updated with no risk-profile change; risk profile increased or decreased with rationale; EDD initiated or refreshed; transaction-monitoring parameters adjusted; screening parties added or changed; specialist review requested; suspicious-activity investigation referred; product or channel restriction proposed; relationship-governance decision requested; or separate sanctions action linked.

A decrease in risk deserves as much evidence as an increase. Controls should not be permanently ratcheted upward because systems make downgrades difficult. FATF's risk-based approach is about proportionality. If the facts that justified enhanced measures no longer apply and the local framework permits adjustment, the bank should be able to record a reasoned change while preserving history.

Downstream updates should be acknowledged. If the customer-risk engine sends a revised risk tier to monitoring, the interface should record whether monitoring accepted it. If screening needs a new beneficial owner, the review should not close until the screening population is updated or an exception is formally owned. This is a key acceptance criterion for technology delivery: business completion and technical propagation are different states.

Roles and governance

The first line normally owns customer understanding and operational execution, but the exact model varies. Relationship teams may obtain information; KYC operations may perform verification and review; financial-crime compliance may set methodology, challenge higher-risk decisions and interpret policy; sanctions teams handle sanctions applicability; investigations teams assess suspicious activity; data and technology teams maintain feeds and workflow; quality assurance tests execution; and internal audit independently assesses control design and effectiveness.

Governance should define who can change review scope, who can approve risk-rating changes, when specialist advice is mandatory, how conflicts with commercial teams are resolved and how policy exceptions are recorded. High-risk does not automatically mean the relationship must be terminated, and commercial importance does not justify suppressing risk conclusions. Decision rights should make both statements operationally true.

Management information should show more than completion rate. Useful views include due and overdue reviews by risk, trigger volumes by source, time from event detection to materiality decision, cases awaiting customer information, deferrals, risk-profile changes, EDD referrals, quality findings, repeated trigger failures, downstream propagation failures and feed-coverage incidents. Metrics should support diagnosis rather than reward fast closure at the expense of quality.

Quality assurance: test the reasoning, not only the checklist

QA should ask whether the reviewer understood the change, selected an appropriate scope, used reliable evidence, considered relevant risk implications, respected jurisdiction-specific rules, documented alternatives and propagated the outcome correctly. A file can contain every required attachment and still be analytically weak.

Sampling should be risk informed and should include difficult cases, not only random easy files. Useful strata include high-risk customers, material ownership changes, PEP changes, reviews triggered by monitoring, overdue cases, downgraded risk profiles, deferrals and cases completed through automation. The bank can use statistical sampling where appropriate, but no universal confidence level or sample size applies to every review programme. The method should be defensible for the assurance objective.

Findings should feed back into training, procedures, trigger rules and system design. If QA repeatedly finds that reviewers miss indirect control changes, the answer may be better ownership data and workflow prompts rather than more generic training. If analysts close cases with missing downstream acknowledgements, the system may need a hard completion gate. Quality is strongest when it changes the control, not when it merely scores people.

BA, architecture and testing considerations

For a business analyst, the most important requirement is to make the decision model explicit. Avoid a user story that says only “when customer data changes, create a review.” Define the event sources, fields monitored, materiality criteria, deduplication behaviour, review scope, mandatory tasks, evidence requirements, escalation rules, decision rights, downstream updates, audit fields and failure handling.

Test cases should include positive, negative and interaction scenarios. Positive tests prove that a material beneficial-owner change, meaningful business-model shift or reliable PEP event creates the intended review. Negative tests prove that immaterial data changes do not flood the queue. Interaction tests prove that multiple related triggers consolidate correctly. Failure-mode tests cover stale external feeds, duplicate events, late-arriving events, incorrect entity matches, unavailable downstream systems, customer non-response and reopened cases. Historical-effective-date tests confirm that investigators can reconstruct what the bank knew at a particular point in time.

Jurisdiction tests are essential for global platforms. The same event can create different legal obligations for different booking entities. A common workflow may therefore need policy configuration by legal entity and jurisdiction while preserving group standards. The design should expose the applicable policy version to the analyst rather than silently applying a global default.

Mini case: a logistics company changes ownership and corridors

Consider a long-standing logistics customer operating mainly within Western Europe. The bank's existing profile records two family owners, predictable freight payments and modest activity with Asian counterparties. A corporate-registry feed then shows that 55 percent of the company has been acquired by a holding company in another jurisdiction. In the same month, payment monitoring identifies a sustained increase in receipts from new counterparties and outward payments to freight agents on routes the customer has not previously used.

The events are correlated into one review rather than three separate cases. The reviewer first confirms that the registry change relates to the correct legal entity and establishes the new ownership and control chain. The new holding company is not prohibited, but its structure introduces an additional layer and a new beneficial owner. Screening is refreshed for the relevant parties. The analyst then examines whether the new corridors are consistent with the company's announced expansion, reviewing contracts and business rationale rather than treating geography alone as suspicious.

The evidence supports a genuine acquisition and business expansion, but the customer's previous risk profile is no longer current. The bank updates ownership and expected activity, increases the customer's risk under its approved methodology because of the new ownership complexity and corridor exposure, and applies the additional CDD and monitoring measures associated with that profile. No suspicious-reporting conclusion is embedded in the risk-rating change; the evidence does not currently establish suspicion under the applicable local threshold. No sanctions action is required. The review record explains these separate conclusions.

Three months later, monitoring identifies activity consistent with the updated profile. That is important. A review is not successful merely because it increased a risk score. It is successful because the bank now has a defensible, current understanding that lets later monitoring distinguish expected business growth from behaviour that would require investigation.

What good looks like

A mature review framework has five characteristics. It knows which facts it is trying to keep current. It can detect material change between scheduled reviews. It selects review depth proportionately rather than rebuilding every file. It keeps AML risk reassessment separate from sanctions, suspicious-reporting, fraud and commercial decisions while connecting them through controlled hand-offs. And it can prove that approved changes reached the systems that rely on them.

The most important lesson is simple: ongoing review is not a calendar exercise. It is the controlled maintenance of the bank's understanding of the customer. Periodic schedules can provide a valuable backstop; event-driven review can shorten the time between material change and reassessment; continuous-data models can automate parts of detection. None of them removes the need for reliable evidence, jurisdiction-aware legal interpretation, clear decision rights and an audit trail showing what changed, what the bank concluded and why.

Operational deep dive: event architecture, data lineage and control resilience

The base chapter explains why periodic and event-driven review are complementary. This deep dive focuses on how a bank can implement event-driven maintenance without turning every customer-data change into a KYC case or allowing automation to hide gaps in evidence.

Start with an event contract

A reliable trigger begins with an explicit event contract. The producing system should identify the customer or legal entity, the event type, the changed attribute, old and new values where available, source, source timestamp, detection timestamp and a stable event identifier. Where an external provider supplies the event, the bank should also know the provider, dataset version and matching confidence needed to link the source record to the bank customer.

This sounds technical, but it solves a common control problem. If the KYC workflow receives only “ownership changed”, the reviewer cannot tell whether the event came from a company registry, a relationship manager, an unverified customer submission or an inferred external-data match. Those sources do not have the same evidential weight. Provenance should survive every transformation from source through case creation so that the final decision can be reconstructed.

Event time and processing time should remain separate. A registry may record that a director changed on 1 June while the bank's feed discovers the change on 4 June and a reviewer assesses it on 5 June. Investigators may later need all three dates. Systems that store only “last updated” destroy that history.

Materiality before workflow

The event layer should not automatically equate data change with financial-crime significance. Materiality rules decide what happens next. A verified change to a customer's trading name may be an administrative update. A new controlling owner may require a broader review. A new address can be routine, but a move to a jurisdiction that changes the bank's risk assessment may be material. The rule should explain which characteristic makes the change important.

Rules should be configurable by customer type, legal entity, booking entity and jurisdiction where necessary. They should also support a manual referral route. No rule catalogue can anticipate every combination of facts, and staff should be able to refer a material change discovered during ordinary customer contact without inventing a fake trigger category.

Deduplication belongs before analyst assignment. Multiple source systems may report the same acquisition or directorship change. Correlation can use customer ID, connected-party ID, event type, effective date and source-reference relationships to group events. The objective is not to suppress evidence; it is to present one coherent change story while retaining each source record.

Perpetual KYC architecture linking source systems and external data to change detection, entity resolution, materiality rules, workflow, evidence storage and downstream customer-risk systems, with explicit degraded-feed handling.

Entity resolution is part of the control

External events are useful only if they are connected to the correct customer. Names alone are often inadequate. Company identifiers, registration numbers, tax identifiers, dates of birth, addresses, national identifiers where lawfully available, and other corroborating attributes can improve matching. The required identifiers depend on the dataset and jurisdiction.

A low-confidence match should not silently update the customer. It can route to confirmation. A high-confidence registry event can sometimes support automated factual update where policy allows, but consequential changes such as beneficial ownership, PEP exposure or risk-profile decisions may still require controlled review. The design should distinguish automated detection, automated factual update, and automated decision; they are not the same level of risk.

Evidence state and profile state

The architecture should keep evidence separate from the current customer profile. Evidence is the source material: registry extract, customer declaration, identity record, screening result, contract, transaction analysis or analyst note. The profile is the bank's current interpretation of those facts. If the profile overwrites the evidence, future reviewers cannot understand why a value changed.

A useful data model therefore preserves effective-dated relationships. If Company A was owned by Person X until 30 June and by Company B from 1 July, the graph should preserve both facts rather than simply replacing X with B. That history matters for sanctions analysis, transaction investigations and retrospective regulatory review.

The same principle applies to expected activity. Instead of one mutable free-text field such as “international payments”, structured attributes can capture expected currencies, corridors, counterparties, products, channels and ranges where useful. Review then becomes comparison between observed behaviour and a versioned expectation rather than an argument over old narrative text.

Downstream propagation is part of completion

A customer review can be analytically correct and operationally ineffective if its outcome never reaches screening, transaction monitoring or product controls. The workflow should therefore treat propagation as a controlled step. Each downstream update should have a target, payload version, send time, acknowledgement, failure reason and retry status.

For example, a newly verified beneficial owner may need to enter the screening population. A change in expected countries may alter monitoring context. A revised risk profile may change the intensity of ongoing monitoring or EDD requirements under the bank's methodology. If an interface fails, the review can move to a “decision complete, propagation pending” state rather than pretending the control has taken effect.

This matters during incidents. If a customer-risk platform is available but the monitoring engine is unavailable, the bank needs a known fallback: queue the update, use a controlled manual instruction where justified, or restrict an action if risk cannot be managed safely. Fallback design is institution-specific; the important point is that failure must be visible and owned.

Feed-health and coverage controls

Continuous data can create false confidence. If an external registry feed stops delivering events, “no changes detected” is not a valid conclusion. The bank should monitor feed freshness, expected volumes, schema changes, rejected records and coverage by jurisdiction or customer population. Significant degradation should generate a control incident or compensating action according to policy.

Coverage also needs mapping. A provider may support company-director changes in one country but not beneficial-ownership changes, or may deliver data with delay in another jurisdiction. The control inventory should state what each feed can and cannot detect. Analysts and governance teams then understand where scheduled review remains an important backstop.

Automation without mystery

Automation is valuable when it reduces mechanical work. Field comparison, source retrieval, document expiry reminders, registry-change detection, task routing and mandatory-field checks are good candidates. Some banks may use statistical or machine-learning methods to prioritise events or identify unusual patterns, but these are optional design choices, not regulatory requirements.

Where models are used, governance should focus on the decision they influence. A model that merely ranks a review queue carries different customer and legal consequences from a model that automatically closes cases or changes a risk profile. Testing should examine data quality, stability, explainability appropriate to use, segment performance, overrides and failure behaviour. Human reviewers need enough information to challenge the system rather than being shown an unexplained score that becomes the de facto decision.

Testing the architecture

A strong test pack follows an event end to end. Create a known ownership change at source, verify that the event is captured once, matched to the correct legal entity, assessed for materiality, routed to the correct workflow, supplied with the source evidence, resolved with the intended profile change, and propagated to screening and monitoring. Then test the opposite: an unrelated company with a similar name must not change the customer's profile.

Failure testing should include late events, duplicated events, changed source schemas, stale feeds, low-confidence matches, downstream rejection, customer non-response, reopened reviews and conflicting source information. Historical tests should prove that the bank can reconstruct what it knew and which profile version was active at a chosen past date.

The engineering objective is not “real time KYC”. It is controlled change awareness: reliable sources, visible coverage, explainable materiality, evidence-preserving workflow and confirmed propagation. That is what makes event-driven review operationally stronger than a faster version of the same old checklist.

Advanced practice: worked review cases

The cases in this section are fictional composites. They illustrate decision logic without claiming that one institution, regulator or jurisdiction would reach an identical result. Each case follows the same discipline: identify the trigger, verify what actually changed, select review scope, distinguish AML customer-risk conclusions from other control decisions, and record the outcome with evidence.

A reusable case pattern for event-driven review: verify the signal, assess materiality, select scope, test explanations, update the profile and route any separate sanctions, fraud or suspicious-activity decision.

Case 1: business-model drift that no single trigger captured

A corporate customer was onboarded as an importer of household textiles. Over two years its payment activity gradually shifts toward electronics components and industrial equipment. No single month looks extraordinary and each new counterparty is individually plausible, so simple threshold triggers do not create a review. A scheduled review finally compares the current portfolio with the original purpose statement and shows that the customer is now effectively operating a different business.

The review should not begin by assuming export-control or proliferation risk merely because electronics appear. The analyst first verifies the current business model, products, suppliers, buyers and countries. Product or trade specialists may be needed where goods descriptions are technically significant. The customer profile is then updated to reflect the actual activity, and the bank assesses whether the new activity changes its ML/TF risk factors or requires other specialist controls.

The control lesson is that event-driven detection should include cumulative change, not only single-event thresholds. Portfolio mix, corridor mix, product usage and sustained deviations from expected activity can reveal a material transformation that point-in-time rules miss. Periodic review remains a useful backstop precisely because no event catalogue is perfect.

Case 2: a customer becomes politically exposed

A retail customer who had no political exposure at onboarding is appointed to a prominent public function. The bank's PEP screening process identifies the change. That event should be handled under the PEP requirements applicable to the booking entity and should also cause the customer profile to be reassessed where relevant.

The review verifies identity carefully because common names can generate false matches. If the person is confirmed to be the customer, the bank applies the measures required by local law and policy, which can include senior-management approval, source-of-wealth or source-of-funds measures and enhanced ongoing monitoring depending on the PEP category and jurisdiction. The review record should not describe the customer as corrupt or suspicious merely because PEP status is confirmed.

If transaction analysis reveals separate facts suggesting corruption proceeds, those facts move to the investigation and suspicious-reporting process. The PEP-driven risk review and the reporting decision remain linked but distinct. The lesson is that status changes can be strong review triggers while still requiring identity resolution and jurisdiction-specific decision logic.

Case 3: ownership changes after a private acquisition

A medium-sized manufacturing customer is acquired by an investment vehicle. The registry feed identifies the new shareholder, while relationship management receives new constitutional documents and a revised board list. The event layer correlates these signals into one case.

The analyst reconstructs ownership and control rather than merely replacing one shareholder name with another. The new structure contains several holding companies and a management vehicle. The bank identifies the natural persons it is required to identify under the applicable CDD framework and examines any other persons exercising control where relevant. Screening is refreshed for newly relevant parties.

The acquisition itself is legitimate and well documented. The risk profile nevertheless changes because ownership complexity, financing arrangements and geographic exposure have changed. The bank updates the profile and associated monitoring according to its methodology. No suspicious report is filed simply because the structure became more complex. The lesson is that event-driven review should preserve the difference between complexity requiring understanding and evidence supporting suspicion.

Case 4: unusual activity challenges the existing customer story

A professional-services firm was expected to receive fees from domestic corporate clients. Monitoring later shows sustained incoming payments from unrelated individuals followed by rapid transfers to payment-service providers abroad. The alert investigator cannot reconcile the pattern with the stated business model and refers the new facts for customer reassessment while continuing the investigation.

The KYC reviewer does not close the monitoring case or determine the local suspicious-reporting threshold. Instead, the reviewer tests whether the customer's purpose, products, counterparties or business model have changed. Customer contact may be appropriate, but the investigation team and MLRO function should consider whether questions could prejudice an investigation or create tipping-off concerns under applicable law.

If the customer provides reliable evidence of a new, legitimate consumer service, the profile can be updated and monitoring expectations recalibrated. If the explanation is inconsistent or unsupported, the bank may apply EDD and relationship restrictions while the investigation proceeds. The lesson is that monitoring can trigger KYC reassessment without turning every alert into an automatic risk increase.

Case 5: sanctions information arrives during a scheduled review

A corporate customer is already undergoing routine review when the bank receives a sanctions-list update concerning a connected party. The sanctions system creates an urgent potential-match workflow. The KYC review must not delay that process.

The sanctions team resolves identity and applicable ownership or control questions under the relevant regime. If legal restrictions apply, the required asset or transaction action is taken according to that regime and jurisdiction. The customer-review team then incorporates verified ownership and control information into the customer profile and evaluates any wider AML/CFT implications.

This case is deliberately simple because the decision boundary is essential: scheduled or event-driven KYC review is not the legal engine for blocking, freezing, rejecting or releasing assets. A bank may use common data and connected workflows, but the sanctions decision retains its own legal basis and urgency.

Case 6: a high-growth fintech outgrows its original profile

A regulated payments company was onboarded when it operated in one country with a small merchant base. Within a year it adds marketplace clients, expands to several countries and begins processing new payment types. Growth is commercially positive, but the original risk profile is no longer a reliable description of the relationship.

An effective trigger can be based on meaningful changes in products, geographies, customer base or transaction behaviour rather than on one arbitrary volume percentage. The review verifies licensing and operating entities, clarifies the role of merchants or sub-merchants, maps new corridors, assesses how the customer conducts its own financial-crime controls where relevant to the bank's exposure, and updates expected activity.

The result may be a higher or lower customer risk depending on the evidence. Rapid growth alone is not suspicious. The lesson is that dynamic business models need triggers that measure changes to the underlying risk story, not just static account thresholds.

Case 7: customer information conflicts across sources

A corporate customer tells the bank that ownership has not changed, but a reliable registry shows a recently filed controlling shareholder. A commercial data provider still shows the old owner, and the relationship manager believes the registry filing may relate to an internal reorganisation.

The correct response is not to choose the source that best fits the previous profile. The review records the conflict, checks effective dates and source authority, obtains supporting documents where necessary and determines which evidence can be relied upon. If uncertainty remains material, the bank can apply a conservative scope and escalate rather than manufacturing certainty.

This case demonstrates why data lineage belongs in review design. Analysts need source, timestamp and effective date, not just a single “owner” field copied from whichever system updated most recently.

Case 8: overdue reviews and risk-based triage

A bank discovers a large backlog after a migration. Some cases are scheduled reviews of stable lower-risk customers; others concern recent ownership changes, PEP events and customers with unresolved transaction-monitoring referrals. Treating the queue first-in-first-out would be easy to administer but weak from a risk perspective.

The bank builds a transparent inventory and prioritises using the nature of the trigger, customer risk, legal urgency, age and available compensating controls. Sanctions or other legally time-critical matters remain outside ordinary backlog sequencing. Management approves temporary capacity and records any review deferrals with expiry dates and controls.

The lesson is not that one scoring formula is globally correct. It is that backlog governance should make risk and urgency visible. A completion percentage that excludes deferred or failed-migration cases is not useful assurance.

What these cases teach

Across all eight cases, the strongest review programmes do not confuse a trigger with a conclusion. A trigger says look again. Evidence says what changed. The bank's methodology says how the change affects customer risk. Separate legal and operational frameworks then decide sanctions actions, suspicious reporting, fraud containment, product restrictions or relationship exit where relevant.

That separation produces better investigations and better technology. It also protects customers from automatic adverse outcomes caused by noisy data while allowing the bank to react quickly when genuinely material change occurs.

Practice close: delivery artefacts, acceptance criteria and testing

A review framework becomes useful only when policy can be translated into requirements that operations and technology can execute consistently. The artefacts below are intentionally implementation focused.

Minimum business requirements

For every review type, requirements should define the population in scope, triggering condition, legal-entity or jurisdiction configuration, materiality logic, permitted review scopes, required evidence, decision rights, escalation routes, downstream updates, closure conditions and audit fields. A statement such as “high-risk customers are reviewed more frequently” is a policy direction, not an implementable requirement. The delivery team needs to know which approved policy determines the interval, how a risk change affects the next due date and what happens when a review is already open.

Event-driven requirements should identify source and provenance. Each trigger should carry an event ID, customer or entity identifier, trigger type, source, source timestamp, detection timestamp and materiality result. Related events should be correlatable so that one acquisition does not create several independent reviews that reach inconsistent conclusions.

Acceptance criteria that matter

A material ownership change should create the intended review for the correct legal entity and expose the source evidence to the reviewer. An immaterial administrative change should either update under an approved low-risk rule or close without creating unnecessary work. A low-confidence external match should require confirmation rather than silently changing the customer profile.

A completed review should preserve the old and new customer-profile values, effective date, evidence, reviewer conclusion and applicable policy version. Where the outcome changes screening parties, monitoring context or another downstream control, closure should require successful propagation or an explicitly owned exception. “Saved in KYC” is not the same as “implemented across the control environment.”

Sanctions events should retain a separate urgent decision path. The KYC workflow may receive verified ownership or identity information, but it must not delay a blocking, freezing, rejecting, release or reporting decision that is required under applicable sanctions law. Fraud containment and suspicious-reporting decisions should be separated for the same reason.

Test the ordinary case and the awkward case

Positive tests should cover a verified beneficial-owner change, a material business-model change, a PEP status event, a sustained change in expected geography and a scheduled review that confirms no material change. Negative tests should prove that duplicate events, formatting-only changes and unrelated external records do not generate inappropriate cases.

Interaction testing should cover multiple triggers for the same underlying event, an event arriving while a periodic review is already open, a risk-rating change during review, and a review reopened after new evidence arrives. Jurisdiction tests should prove that the same event can route to different policy tasks where booking entities are subject to different legal frameworks.

Failure-mode tests are essential. Simulate an unavailable registry feed, delayed event, schema change, entity-resolution failure, downstream interface rejection, customer non-response and queue overload. The system should expose degraded coverage and ownership rather than silently behaving as if no change occurred.

Historical reconstruction should also be tested. Select a past date and prove that an investigator can identify the customer profile, ownership graph, evidence and policy version that were in force at that time. This is particularly important when a later investigation asks what the bank knew before a transaction or decision.

Useful management information

Review MI should help management diagnose the control, not just celebrate throughput. Useful measures include due and overdue reviews by risk, event volumes by source, time from event detection to materiality decision, open cases waiting for customer information, deferrals, risk-profile changes, EDD referrals, QA findings, duplicate-trigger rates, feed-health incidents and failed downstream propagation.

Do not turn these measures into universal numerical targets copied from another institution. Thresholds and service levels should reflect applicable law, risk appetite, product design and operational capability. The important governance question is whether the bank can identify material change and respond in time for the resulting control decision to remain effective.

Analyst close-out check

Before closing a review, the analyst should be able to answer five questions in plain language: What changed? What evidence proves it? Why was this review scope appropriate? Did the change alter the customer risk or require another control decision? Did the resulting updates reach every required downstream system? If any answer is unclear, the file is not ready merely because all workflow boxes are ticked.

Masterclass: when a technically complete review is still wrong

A useful way to test review governance is to examine a failure that does not look like one. Imagine a bank where every scheduled KYC review is shown as complete on time. The dashboard is green, the operations team meets its service level, and quality sampling finds that required documents are present. Yet a later investigation discovers that several customers had materially changed business activity months earlier and their transaction-monitoring expectations were never updated.

The problem is not missing paperwork. It is that the control measured workflow completion rather than customer-understanding currency.

How the failure develops

The review platform calculates due dates from customer risk tier. Relationship managers collect updated customer declarations, operations verify required fields, and the reviewer confirms that mandatory documents are present. The process has no structured comparison between expected and observed transaction behaviour, no registry-change feed, and no downstream acknowledgement from transaction monitoring. A reviewer can therefore close a file without discovering that the customer now uses different countries, counterparties or products from those recorded at onboarding.

The bank also has event-driven triggers, but they are owned by separate teams. Transaction monitoring can refer a case to KYC, adverse-media screening can create a task, and corporate-registry data can identify changes. The triggers do not share one correlation identifier, so several events can create separate tasks while another event may be missed because each team assumes another queue owns it.

Management information hides the weakness. It reports reviews completed, reviews overdue and average handling time. It does not report material profile changes detected outside review, cases closed without observed-behaviour comparison, trigger-to-review latency, failed data feeds or downstream propagation failures.

The investigation that exposes the gap

An investigation begins with unusual payments from a long-standing corporate customer. The investigator discovers that the customer had expanded into a new line of business roughly a year earlier. The change was visible in payments, website information and a company-registry filing. A scheduled review occurred during that period, but the analyst only confirmed legal name, address, directors and existing ownership documents. The stated nature and purpose of the relationship was copied forward.

This does not prove that the bank violated a particular law merely because a review was narrow. The legal assessment depends on the booking entity, applicable rules and facts. But it does show a control-design problem: the review could be completed without testing whether the bank's understanding remained reliable.

Redesigning the control

The bank first changes the review objective. The output is no longer “CDD refreshed”; it is “current customer understanding established to the scope required by policy”. That outcome requires explicit comparison between the prior profile and current evidence.

Second, the bank creates a common event layer. Registry changes, customer declarations, monitoring referrals and external-risk events retain their source and timestamps, and related events can be correlated. Materiality rules determine whether a factual update, targeted review or broader reassessment is needed.

Third, the review workflow adds decision boundaries. A sanctions event can route immediately to sanctions operations without waiting for KYC. A monitoring referral can continue through investigation while verified customer facts are updated. The KYC reviewer records customer-risk implications but does not decide the suspicious-reporting threshold merely by changing a risk tier.

Fourth, the bank makes downstream propagation visible. If a revised risk profile or beneficial owner must reach screening or monitoring, the review cannot be operationally complete until the target system acknowledges the update or a controlled exception is owned.

Finally, management information changes. Completion rate remains useful, but it is accompanied by trigger coverage, event ageing, risk-profile changes, deferrals, QA findings, feed health and propagation failures. Management can now see whether the programme keeps customer understanding current, not simply whether cases move through a queue.

Governance lesson

A bank can have excellent analysts and still run a weak review control if the workflow asks the wrong question. Equally, a sophisticated “perpetual KYC” platform can fail if external feeds are stale, entity matching is weak or downstream systems never receive the result.

The masterclass lesson is that review governance should follow the information lifecycle end to end: detect change, verify evidence, reassess proportionately, preserve decision boundaries, propagate the outcome and prove the control worked. A green completion dashboard is meaningful only when those steps are true underneath it.

Knowledge checks with explained answers

1. Does FATF Recommendation 10 require every bank to review high-risk customers annually and lower-risk customers every three or five years?

No. FATF requires ongoing due diligence and expects CDD information to be kept up to date and relevant, particularly for higher-risk customers, but it does not prescribe one universal global review calendar. A bank must follow the law and supervisory expectations applicable to its entities and then implement an approved risk-based policy. Internal intervals should never be described as if they were FATF rules.

2. What is the difference between a trigger and a review outcome?

A trigger is information that may make the existing customer picture unreliable or incomplete. It tells the bank to assess the change. The outcome comes after evidence is verified and can be no change, factual update, risk reassessment, EDD, monitoring adjustment or another controlled action. Treating every trigger as a risk increase creates false positives and weak customer outcomes.

3. A company registry reports a new beneficial owner. Should the bank automatically overwrite its customer record?

Not necessarily. The bank should first resolve the event to the correct customer, understand the source and effective date, and apply the verification standard required by its legal framework and policy. A reliable registry event may be strong evidence, but low-confidence matching or conflicting sources may require analyst confirmation. The ownership history should remain reconstructable rather than being overwritten without trace.

4. A transaction-monitoring alert is escalated to KYC because the activity does not fit the stated business purpose. Does the KYC reviewer decide whether to file an STR or SAR?

Normally that decision belongs to the investigation or reporting process established under the applicable jurisdiction. The KYC reviewer can reassess the customer profile and provide verified information. Customer risk and reportable suspicion are related but different decisions.

5. What happens if a sanctions designation appears while a customer is undergoing periodic review?

The sanctions decision must follow the applicable sanctions regime and its urgency. A KYC review must not delay blocking, freezing, rejecting, restricting, release or reporting action where the law requires it. The review can use the verified sanctions analysis to update customer information and wider risk understanding afterward.

6. Why is a first-in-first-out backlog not always risk based?

Because age is only one dimension of urgency. A recent material ownership event, PEP change or monitoring referral can require faster attention than an older routine review. Backlog prioritisation should consider the nature of the event, customer risk, legal urgency and available controls. Legally time-critical sanctions or fraud actions may sit outside the ordinary review queue entirely.

7. What is the main control risk in “perpetual KYC”?

False confidence. Continuous event feeds can improve currency, but only if the bank knows their coverage, freshness, entity-resolution quality and failure state. An unavailable registry feed must not be interpreted as proof that nothing changed. Continuous detection also does not remove the need for human judgement where evidence is ambiguous or consequences are significant.

8. When is a review operationally complete?

When the required assessment is complete, the reasoning and evidence are recorded, and any required downstream changes have either been successfully implemented or placed under a controlled, owned exception. Saving a new risk rating in the KYC platform is not enough if monitoring, screening or other dependent systems still use the old information.

Glossary

Ongoing customer due diligence (ongoing CDD): continuing scrutiny of the relationship and maintenance of relevant customer information so the bank's understanding remains current under the applicable AML/CFT framework.

Periodic review: a review scheduled according to applicable law, risk methodology and bank policy. The interval is not globally uniform.

Event-driven review: a review initiated because new information may be relevant to the customer's CDD or risk profile.

Trigger: the event or signal that prompts assessment. It is not the conclusion.

Materiality: the significance of a change to the bank's understanding of the customer, relationship or risk. Materiality criteria should be documented and context aware.

Targeted refresh: a narrow review addressing a defined change without rebuilding the whole customer file.

Comprehensive review: broader reassessment used where existing CDD is no longer sufficiently reliable, accumulated changes are significant or policy or law requires greater scope.

Perpetual KYC / continuous KYC: an operating model that uses ongoing change detection to refresh customer information closer to material events. It is not a separate universal legal obligation.

Event provenance: information showing where a trigger came from, when it arose, what changed and how it was linked to the customer.

Entity resolution: the process of determining whether an external record or event relates to the bank's actual customer or connected party.

Effective date: the date from which a fact or relationship is understood to apply, which can differ from the date the bank discovered or processed it.

Review backlog: reviews or review tasks that remain unresolved beyond the bank's intended or required handling window.

Deferral: an approved postponement of a review or task under defined governance, usually with reason, expiry and any compensating control recorded.

Downstream propagation: transmission of an approved customer-profile change to dependent controls such as screening, monitoring or product systems.

Decision boundary: the separation between related control decisions, for example customer-risk reassessment, sanctions disposition, suspicious reporting, fraud containment and relationship exit.

Customer-understanding currency: the degree to which the bank's current customer profile remains supported by reliable, relevant and sufficiently recent evidence.

References and further reading

The chapter uses FATF as the global standard baseline and then uses regulator or legal sources to show how ongoing CDD is implemented differently by jurisdiction. The links below were checked on 17 September 2026.

Global standard

United States

Australia

United Kingdom

European Union

Accuracy note

The global principle is ongoing, risk-based customer due diligence and maintenance of relevant customer information. Exact review intervals, event triggers, reverification requirements, PEP measures, suspicious-reporting thresholds and customer-restriction rules differ by jurisdiction and institution. The bank must apply the law, regulatory guidance and approved policy applicable to the relevant legal entity and relationship; examples in this chapter are educational and are not transaction-specific legal advice.