An event-driven KYC review updates a customer's due diligence when a trigger event shows something relevant has changed, instead of waiting for a scheduled date. Its weak point is invisible by construction: an event that is never linked to the customer, or is wrongly judged not material, produces no review, no ticket and no complaint. The only way to measure that is to test with events whose answer you already know. Take a past quarter of real feeds, plant a set of known material events in it (an owner change, a new country, an adverse article about a real owner), replay it and count how many reached an analyst, how fast and with the right sections. Then keep testing in production by sampling the "no action" calls every day. Botminds' Perpetual KYC (pKYC) does the daily sampling by design, and the seeded replay is how a bank should test it, or any event-driven program, before trusting it.
What a controlled test showed about rules against models, on synthetic data
25%
of money launderers, at most, found by rule-based monitoring in a siloed scenario
2×
more than twice as many found by machine learning models on the same data
~80%
found by the model with a cross-border view of the data
What is an event-driven review in KYC?
An event-driven review in KYC is an update to a customer's file started by a change in the customer's circumstances, such as a new owner, a new country or activity outside the expected profile, rather than by a calendar date. It is the core of perpetual KYC, and US rules support it: the duty to update customer information is risk based and arises from normal monitoring, with no fixed schedule. The trigger events regulators have named are the usual starting list.
The term is used in AML too, for reviews of a customer's activity after an alert. The two meet in practice: a transaction monitoring alert that shows activity outside the profile is one of the most common triggers for a KYC review, and a KYC change, such as a new high-risk country, changes what monitoring should expect.
Why recall is the number nobody reports
Recall, the share of material events that actually reach an analyst, is the measure that decides whether an event-driven program is safe, and it is the one most programs cannot produce. A queue shows what was caught. Quality control on closed events shows whether the calls that were made were right. Neither shows what never became an event at all.
There are three ways an event goes missing. The feed never delivers it: the registry service skips a jurisdiction, the media service falls behind. The link fails: the event is attached to no customer or the wrong one. Or the rule fails: the event is linked and judged, but the trigger policy calls it not material when it is. Only the last kind can be found by sampling closures; the first two need a test in which the right answer is known in advance.
The cost of not measuring is documented. In April 2026 the OCC found that a bank's automated alert triage, because of deficiencies in its logic, data and methodology, had been closing alerts that should have been escalated, and had done so for a very high share of everything it ingested (OCC, Community Federal Savings Bank, 2026). A seeded test before go-live is designed to find exactly that.
How to test KYC triggers: the seeded replay
To test KYC triggers, replay a real past period through the system with known events planted in it, and score what comes out against the answer key. The method borrows from how detection systems are tested elsewhere: if you want to know whether a net catches fish, put in fish you have counted.
A seeded replay for an event-driven KYC review, step by step
- Choose the period
A recent quarter of real feeds from every source: registry, core, screening, media, monitoring, lifecycle.
- Write the answer key first
For each planted event: the customer, whether it is material, under which rule, and which sections it should touch.
- Plant events of every type
Owner changes, indirect ownership through a foreign company, new countries, new products, real-owner adverse news, address moves that should not matter.
- Plant hard cases on purpose
Name variants, a new owner just under and just over 25%, an owner of an owner, a namesake in the news.
- Freeze the trigger policy version
Score against the rules in force, so a failure can be traced to a rule or to the system.
- Replay without telling the reviewers which events are planted
Analysts and QC work the replay as normal.
- Score recall, accuracy and time
See the scoring table below; report by event type, not as one number.
- Fix, then re-run the failures
A missed type is a feed, link or rule problem; each has a different owner.
Building the seed set
A seed set should mirror the bank's trigger policy, with at least a few events for every rule and deliberate edge cases at every threshold. It should also include events that must not be material, because a program that escalates everything has perfect recall and no value.
An illustrative seed set for one quarter, and what counts as caught
| Planted event | Should be | Counts as caught when |
|---|---|---|
| New direct owner of 30% | Material under the owner rule | Reaches an analyst with the owners section redrafted and the owner screened |
| New owner of 30% through a foreign holding company | Material under the owner and country rules | The indirect owner is identified by name, not just the holding company |
| New owner of 24% | Not material | Closed with the rule and reason, and the stake shown |
| Wires to a new country in a top risk tier | Material | Reaches an analyst with geographies and expected activity touched |
| Adverse article about a namesake | Not material | Closed with the identifiers that rule out the match |
| Adverse article about the actual owner | Material, or to the sanctions team if a list match | Escalated, never cleared |
| Consumer moves within the country | Not material | Closed with the rule and reason |
| Consumer moves to a commercial mail receiving agency | Material | Reaches an analyst |
The size of each group matters more than the total. A test with 200 planted events of which 150 are address changes says little about owner changes. As a rule of thumb from simple probability, catching all of 30 planted events of one type supports, at 95% confidence, a miss rate below about 10% for that type; catching all of 59 supports about 5%. That is our arithmetic, and it assumes the planted events are representative of the real ones.
Scoring the replay: recall, closure accuracy and time
Score four numbers, by event type: recall of material events, accuracy of not-material closures, accuracy of the sections touched, and time from the event to an analyst. Report them separately, because a single blended accuracy figure hides the type that is failing.
Four numbers to report from a seeded test, and what each one finds
| Number | How it is computed | What a failure points to |
|---|---|---|
| Recall | Planted material events that reached an analyst ÷ planted material events | A feed gap, a linking failure or a rule that is too narrow |
| Closure accuracy | Planted not-material events correctly closed ÷ planted not-material events | A rule that is too broad, or noise the analysts will learn to ignore |
| Section accuracy | Caught events with the right sections touched ÷ caught events | A trigger-to-section map that misses part of the file |
| Time to analyst | Minutes from the event's arrival to routing, median and worst | A slow feed or a queue that is not prioritised by risk tier |
How to QC "no action" decisions every day
After go-live, the seeded test becomes a daily sample. Every event judged not material keeps its rule and reason; a fixed share of them goes each day to a QC reviewer who did not make the call, stratified by trigger family so that a rare family is not drowned out; and each family's pass rate is tracked against a floor. When a family falls under the floor, the rule behind it is reviewed.
That is how Perpetual KYC (pKYC) is designed: 10% of the day's not-material calls go to QC, by family, against a 97% pass-rate floor, both of which are bank settings and the sample rate a design target. On October 22, 2026, the fictional sample bank's agents closed 2,172 events as not material by 9:24 AM, and 217 of them were in the day's QC sample.
Perpetual KYC (pKYC) pass rates of 'no action' calls by trigger family: one under the floor
The failing family shows how the loop is supposed to close. QC disagreed with five closures in screening and media that month, all under rule T-19, which closed civil lawsuits with money claims over $1 million without review. The family had been under the 97% floor for three weeks, and the sampler opened a rule review on October 20; the draft version of the policy makes those lawsuits material. Nobody outside the bank had to find it.
Twelve weeks of QC pass rates in Perpetual KYC (pKYC), and the rule review the floor opened
Rules, models and agents: what the research says
The research says detection rates vary widely by method and have to be measured. In its 2023 Project Aurora experiment, the BIS Innovation Hub found that "the rule-based monitoring approach detected only up to 25% of the money launderers in a siloed monitoring scenario, whereas the machine learning models were able to detect more than twice as many" (BIS, Project Aurora). The data were synthetic and the task was transaction monitoring, not KYC refresh, so the numbers do not transfer. The lesson does: the same data, judged by different methods, yields very different recall.
For an event-driven KYC review, that argues for testing each layer separately. The feeds decide what can be seen; the linking decides whether it reaches the right customer; the trigger policy, applied by people or by agents, decides what is material. A seeded replay with events planted at each layer tells a bank which one is losing events.
How to validate perpetual KYC for model risk and examiners
Validate it as a control, with evidence a reviewer outside the team can follow: the trigger policy and its versions, the seeded test and its answer key, the scores by event type, and the daily pass rates since go-live. The agents themselves are outside the interagency model risk guidance, which since April 2026 excludes generative and agentic AI and leaves their governance to the bank (SR 26-2); the risk rating model they call is usually a traditional model within it.
European guidance on automated onboarding offers a template worth borrowing. It asks firms to state which steps run with no person involved and which need one, and lists quality assurance testing, sample testing and manual reviews among the controls for automated steps (EBA/GL/2022/15). The FATF makes the same point more generally: technology can help, but people reviewing and judging what it produces remain essential (FATF, Opportunities and Challenges of New Technologies for AML/CFT, 2021).
Examiners judge the process. The FFIEC manual says a bank with an established and effective risk decision process should not be faulted for individual customer risk decisions unless they affect the program's effectiveness (FFIEC BSA/AML Manual, CDD). A seeded test and a daily sample are how a bank shows that the process, not just one decision, works. A pilot on last year's refreshes uses the same replay to compare a vendor's results with the bank's own history.
Questions people ask
What is event-driven KYC?
It is refreshing a customer's due diligence when a trigger event shows something relevant has changed, rather than on a fixed review date. It is another name for perpetual or continuous KYC, and in the US it rests on FinCEN's position that updating is risk based and follows from monitoring.
What is an event-driven review in AML?
A review of a customer's activity and profile started by an alert or event, such as unusual wires or a screening hit, rather than by the calendar. When the event changes what the bank believes about the customer, the AML review should flow into a KYC refresh of the affected sections.
How do you validate perpetual KYC?
Replay a past period with known events planted in it and measure recall, closure accuracy, section accuracy and time to analyst by event type. After go-live, sample the closed "no action" calls daily by trigger family and act when a family's pass rate falls under the bank's floor.
How many events should a seeded test include?
Enough per event type to support a useful bound, not a large total. Catching all of 30 planted events of a type supports a miss rate below about 10% at 95% confidence; all of 59 supports about 5%, by our arithmetic.
Can quality control sampling replace a seeded test?
No. Sampling closed events measures whether the calls that were made were right; it cannot find events that never arrived or were linked to no customer. The seeded test measures those, so a sound program uses both.