Teams usually move to event-driven refresh because scheduled reviews keep piling up, most find nothing new, and real changes in a customer's risk show up between review dates.
This guide is for a KYC operations lead or BSA officer at a US bank or fintech who has decided to make the move and needs the plan. If you want the definition first, read our glossary entry on perpetual KYC (pKYC). For the CIP and refresh mechanics underneath, see how KYC automation works.
How do you move from periodic KYC reviews to perpetual KYC?
What should you assess before you start?
The failure pattern in these programs is rarely the trigger logic. It is the customer record underneath. Before you wire up a feed, answer five questions.
Can you identify one customer across systems?
A sanctions update is only useful if it lands on the right customer and its related parties. If the core, the onboarding system and the case tool each hold a different version of a company's name, signals will miss or duplicate.
Does your policy say what a trigger does?
Your written CDD procedures should state which events need a refresh, which need only a record update, and which go to enhanced due diligence. An agent cannot follow a procedure that exists only in people's heads.
Which risk-model inputs only change at review time?
If a rating depends on expected activity or ownership fields that are refreshed only at review, an event-driven model needs another route to them.
Who owns each feed?
Each source needs an owner, a delivery rate and a plan for when it is late or wrong.
What is your baseline?
Pull reviews completed by tier, the share that ended with a material change, and analyst time per review, so you can show later whether the change helped.
Fixing the customer record often takes longer than building the triggers, and it benefits every other BSA process that reads it.
What does the regulation actually ask for?
US rules do not mention perpetual KYC by name, and they do not set a refresh interval. For banks, 31 CFR 1020.210(a)(2)(v) requires risk-based procedures for ongoing customer due diligence, including ongoing monitoring to identify and report suspicious transactions and, on a risk basis, to maintain and update customer information. For legal entity customers, that customer information includes beneficial ownership information under 31 CFR 1010.230.
On February 13, 2026, FinCEN issued order FIN-2026-R001, which lets covered institutions limit beneficial ownership identification and verification to three situations: when a legal entity customer first opens an account, when the institution has knowledge of facts that reasonably call earlier information into question, and as needed under its risk-based ongoing due diligence procedures. The second and third are event-driven by their wording. Read the order for scope and conditions, and have counsel confirm how it applies to you.
The FFIEC BSA/AML Manual's customer due diligence section describes the update duty in similar terms: events such as ownership changes, red flags from monitoring or negative media can prompt an update, and the section does not impose a categorical requirement to update customer information on a continuous or periodic basis. In practice, your risk-based procedures decide the mix of calendar and event, and an examiner will ask for your reasoning.
Which events should trigger a refresh?
The table maps common events to a source, the AI employee's task and the decider. Your risk assessment sets the final list.
Trigger | Data source | What the AI employee does | Who decides |
|---|---|---|---|
Sanctions or PEP list change creating a possible match | Your screening tool's re-screen results against updated lists | Pulls the alert, compares identifiers, drafts a match rationale, holds the file open | Analyst on possible matches; sanctions officer on any true match |
Adverse media about the customer or a related party | Media screening vendor alerts | Checks identity of the subject, summarizes the article, rates relevance against policy | Analyst; senior reviewer for high-risk customers |
Beneficial ownership or control change | Customer notice, corporate registry extract, ownership certification | Compares new ownership with the file, flags new owners or control persons, requests a new certification | Analyst confirms; risk owner approves any rating change |
Transaction-behavior shift | Alerts or segment changes from transaction monitoring | Summarizes new geographies, counterparties or volumes against the expected-activity profile | Analyst; investigations team if suspicion arises |
Address, name or contact change | Core banking or onboarding system updates | Verifies the change against supporting evidence, re-runs screening on the new data | Analyst only if verification fails |
Dormant account reactivation | Core banking activity flags | Checks time dormant, recent contact changes and any new signers, requests current information | Analyst for exceptions; operations lead for policy |
Corporate registry event, such as a struck-off or reinstated entity | Registry monitoring feed | Matches the event to the customer, attaches the registry record, opens a case | Analyst; relationship owner for outreach |
For the screening side, see our guides on sanctions screening automation and PEP and adverse media screening.
What data feeds does event-driven refresh need?
You do not need every feed on day one. You need the ones that carry your chosen triggers, each with a way to match the signal to a customer, a stated delivery rate and a record of when it arrived.
Screening and media feeds usually exist already. The change is to run them against the existing customer base whenever lists update. Transaction-monitoring output needs to reach the KYC queue as a structured signal, not an email. Registry and ownership data is the weakest link at most banks: coverage varies by jurisdiction, and customer attestation remains part of the process.
A silent feed is a risk of its own: the file looks quiet when it is actually blind. Alert the owner when a source misses its expected window.
How do you keep trigger noise under control?
Noise is the main reason pilots stall. A trigger that fires on every minor media mention or common-name list update buries analysts in a different backlog than the calendar did.
Set a tolerance for each trigger type before launch. Useful levers are match-confidence thresholds, an identity check before a trigger opens a case, grouping several signals on one customer into one case, and suppressing signals already reviewed and cleared. Record every suppression rule and its reason, because an examiner will ask why a signal did not open a case.
Measure noise as the share of triggered cases that ended with no change to the file or rating. A high share points to a threshold that needs adjusting, or to a trigger that belongs in a lighter record-update path.
How should each triggered case be designed?
A triggered case needs what happened, what the file said before, and the next step. The AI employee builds the first two so the analyst starts from a packet, not a blank screen.
A workable case holds the trigger and its source, the matched customer and related parties, the current rating and last review date, the evidence, a short summary of what changed, and a recommended action under your policy. Actions form a small set: no change, update the record, request information, move to enhanced due diligence, or escalate to investigations.
Keep light paths light. An address change that verifies cleanly can close with a logged record update if your policy allows it. A serious ownership change or any sanctions possible match goes to a named reviewer every time. Changing a rating or exiting a customer is always a person's decision.
Do you still need periodic reviews?
Yes, for part of the book. Some changes never reach a data feed: a business shifting what it does, a new beneficial owner who is never registered, a relationship that has outgrown its stated purpose.
The usual design keeps a calendar where a missed change costs the most, such as high-risk customers and PEPs, and lengthens the cycle for lower tiers once their triggers have run reliably. The calendar also checks the triggers. If scheduled reviews on a lower tier keep finding changes the triggers missed, you have a gap in your signals. If they almost never find anything the triggers did not, you have evidence to support a longer interval, and that evidence belongs in your risk assessment.
What does a phased rollout look like?
Phase the work by trigger type and customer tier, and set an exit test for each phase before you start it.
Phase 1, shadow mode.
Run two or three triggers, such as sanctions re-screening, adverse media and address changes, beside the calendar. The agent builds cases while analysts keep working scheduled reviews. Exit when packets are consistently usable and you have a noise baseline.
Phase 2, live on lower-risk tiers.
Let triggered cases drive reviews for lower tiers while the calendar keeps its old interval. Add transaction-monitoring signals and ownership changes. Exit when noise is within tolerance and sampled calendar reviews show no missed material change.
Phase 3, calendar relief.
For tiers with a clean record, lengthen the interval with your risk committee's approval.
Phase 4, steady state.
High-risk customers keep their periodic backstop. Tuning and sampling continue as standing work, and no phase starts until the previous exit test is met.
Which metrics show whether it is working?
Report a small set to the BSA officer on a regular schedule, using actuals from your own data and not vendor figures.
- Material-change yield.
The share of triggered and of calendar reviews that ended with a change to the file or rating, by tier. - Time from trigger to refreshed file.
From signal arrival to approved update. - Noise rate.
Triggered cases that closed with no change. - Backlog age.
Reviews past due, if you keep a calendar. - Analyst hours per completed refresh, against your baseline.
- Feed health.
The share of expected deliveries that arrived on time.
How do you prepare for an examination?
Expect an examiner to ask how your design follows from your risk assessment, and to sample cases. Have ready the written procedure that defines triggers and actions, the risk assessment behind your mix of calendar and event, logs showing each trigger with its evidence and approver, your tuning and suppression records, and sampling results showing triggers are not missing material changes.
Where an AI agent does part of the work, show what it did and what a person decided. For the model-risk questions examiners raise, see what examiners ask about AI in BSA/AML programs. Background is in our glossary entry on customer due diligence (CDD) and in CDD and beneficial ownership under the FinCEN CDD rule.
How Zamp Approaches Event-Driven KYC Refresh
Zamp builds AI employees that run back-office jobs end to end. For event-driven refresh, the AI employee follows an Agent Operating Procedure that you write and approve: which signals open a case, what evidence to gather, what it may do alone and where it must stop. Unclear signals go to a Needs Attention queue with context attached, a validate step checks output before a case closes, and every trigger, action and approval is logged.
People keep rating changes, exits, sanctions matches and any suspicion that points to a SAR. When a reviewer overrides the agent, the correction is tested against known cases and merged after review, so the procedure improves without changing the model. For the vendors around this work, see our KYC and KYB tools roundup, and for business customers, KYB automation for banks and fintechs.
