Event Driven KYC Review Triggers and How to Wire Them In

Table of Contents

Event driven KYC review triggers are defined changes that force a customer file to be reviewed before its scheduled date. A sanctions designation. A new beneficial owner. A jurisdiction move. An expired passport. A payment pattern that breaks the customer’s stated profile. Each one opens a case, on a clock, with a named owner.

Periodic review alone leaves gaps. If a customer sits on a three year cycle and their ownership changes in month four, the file is wrong for thirty two months. That is just what a calendar does.

Below is the trigger list, how to set thresholds so the queue does not flood, how to wire triggers into the systems that already hold your data, and what the review record must show. It also covers failure modes that are rarely written down, including dead data feeds.

What counts as a trigger event

A trigger is a material change in a customer, their owners or their environment that could alter the risk rating or invalidate part of the file. A customer moving office within the same city is a change but rarely a material one. The same customer moving its operating centre to a country subject to countermeasures is both.

Write the definition into policy before you build anything. If materiality lives only in an analyst’s head, two analysts will reach two answers on the same facts.

The regulatory basis for reviewing between cycles

The FATF 40 Recommendations require ongoing due diligence on the business relationship, including keeping customer data up to date. Recommendation 10 is the anchor. It does not prescribe a calendar. It requires the record to stay current on a risk sensitive basis, which is a harder obligation.

The UK Money Laundering Regulations 2017 carry the same idea in regulation 28(11), which requires firms to keep customer due diligence documents and information up to date. The EU’s Anti Money Laundering Regulation, which applies from 10 July 2027, sets maximum update intervals as well as review on the occurrence of relevant events. The intervals in Article 26 are one year for higher risk customers and five years for the rest. Those are ceilings, not a schedule you can hide behind if you learn something in between.

Sanctions rules sit on a stricter footing again. The prohibition bites the moment a designation takes effect, not at your next review date. That is why screening triggers get their own clock, measured in hours.

The trigger list

Group triggers by the data that detects them. Each group then has to map to a real feed, which keeps the build honest.

Screening and watchlist triggers

A customer, owner, director or authorised signatory becomes a positive or possible match on a sanctions list.
A related party appears on an export control restricted party list, such as an entity list or a denied persons list.
A person in the structure becomes a politically exposed person, or a close associate of one.
Credible adverse media appears naming the customer or a controller in connection with fraud, corruption, sanctions evasion or organised crime.
A list operator amends an existing entry, adding an alias, an address or a vessel that now matches your record.

The last one is missed constantly. Firms check for new list entries but ignore amendments to entries they already cleared. An added alias can turn a clean record into a match with no list addition at all. Set up your denied party screening so amended records are treated as fresh events.

Ownership and control triggers

A change in ultimate beneficial ownership, whether it crosses a threshold or not.
A new intermediate holding company inserted into the chain.
A change of directors, trustees, partners or authorised signatories.
A nominee arrangement discovered or disclosed.
A merger, acquisition, share transfer or insolvency event.

Behaviour and transaction triggers

Transaction volume or value moving materially outside the range agreed at onboarding.
New counterparty countries that were not in the stated trading pattern.
A change in goods, services or sector.
Third party payments, or payments routed through a jurisdiction with no commercial link to the trade.
A suspicious activity report filed on the relationship.
Dormancy followed by reactivation, especially with a new signatory.

Documentary and data triggers

Identity documents past their expiry date.
Registered address, legal name or trading name changed.
Licence, registration or regulatory authorisation lapsed, suspended or withdrawn.
A gap or contradiction found during other work, such as a trade finance review.

External and jurisdiction triggers

A country in the customer’s footprint is added to a high risk or call for action list.
A new sanctions programme or sectoral measure covers the customer’s industry.
An export control rule change brings the customer’s goods into scope.
A regulator, court or insolvency notice names the customer.

Most published trigger lists stop at the AML set and leave out trade control triggers. If you export, that omission is expensive. A licence condition change or a new entity listing can make a planned shipment unlawful with no change at all on the customer’s side. Build the red flags of sanctions evasion into the behaviour trigger set rather than leaving them to analyst judgement.

Trigger, source, response and clock

A trigger list is not a control until each entry has a detection source, a default response, an owner and a deadline. Adjust the clocks below to your own risk appetite and regulator expectations.

Trigger	Detection source	Default response	Owner	Target clock
Sanctions match on customer or owner	Screening platform, daily list refresh	Freeze pending review, escalate to MLRO, assess reporting duty	Sanctions team	Same day
Restricted party list hit on a consignee or freight agent	Trade screening at order or booking	Hold the shipment, check licence position	Export compliance	Before release
New PEP identified in the structure	PEP data feed, customer disclosure	Risk reassessment, senior approval to continue, source of wealth	KYC analyst plus approver	5 business days
Beneficial ownership change	Corporate registry feed, customer notice	Re-verify UBOs, screen new parties, refresh structure chart	KYC analyst	10 business days
Adverse media on a controller	Media screening feed	Assess credibility and relevance, then rate or dismiss with reasons	KYC analyst	10 business days
Transaction pattern outside expected range	Transaction monitoring	Confirm purpose, update expected activity, consider EDD	Monitoring team then KYC	15 business days
Jurisdiction added to a high risk list	Policy team bulletin	Batch reassessment of every affected customer	Policy plus KYC	30 calendar days
Expired identity document	Document expiry job in the KYC system	Request replacement, restrict activity if not supplied	Onboarding operations	30 calendar days
Dormant account reactivated	Core banking or ERP activity flag	Re-verify signatories, rescreen, confirm purpose	Relationship owner	Before next transaction

Setting thresholds so the queue stays workable

An unfiltered trigger engine will bury a team. Grade the response instead of running one review type. Give every trigger one of four outcomes.

No action, logged. The change is recorded and nothing else happens.
Targeted check. One field is verified and the file updated. No full refresh.
Risk reassessment. The rating is recalculated and the outcome recorded.
Full refresh. The whole due diligence pack is renewed and re-approved.

Calibrate with real data before you switch anything on. Replay six or twelve months of historical changes against your draft rules and count what would have fired. If a rule would have produced thousands of cases and none would have changed a rating, the threshold is wrong. If a rule fires ten times and eight became escalations, keep it and tighten the clock.

Thresholds should differ by risk tier. A five percentage point shift in ownership may be immaterial for a low risk domestic customer and material for a high risk one with exposure to a sanctioned region. Write the tier specific numbers into policy so audit can test them.

Wiring triggers into systems

Triggers need a single customer record to attach to. If the same company exists three times across onboarding, screening and the trade system, a trigger on one copy will not reach the other two. Entity resolution comes first.

Then connect the feeds. Screening lists, corporate registries, media providers, transaction monitoring, the document expiry job, and your own case history. Each feed should write an event with a timestamp, a source name and a payload showing the old and new values. Analysts need to see what changed, and a bare flag does not tell them.

Detection date is not event date

Record both. A registry filing dated in March that your feed picks up in June creates a three month exposure window you have to explain. Run the clock from detection, since that is when you could act. Run the risk assessment from the event date, since that is when the customer changed. Firms that store only one date cannot answer the obvious audit question about the gap.

Monitor the feeds as well as the alerts

A broken feed produces zero triggers, and zero triggers looks identical to a clean book. This is the most dangerous silent failure in event driven KYC, and almost nobody writes about it.

Build a heartbeat. Every feed should report its last successful run, its record count and its variance against the previous period. Add canary records, dummy customers built to match a known list entry or to expire on a fixed date. If the canary does not fire on schedule, the pipeline is down. Review feed health at the same committee that reviews alert volumes.

Propagate triggers across connected customers

When a person is designated, the file that matched is rarely the only one affected. That person may be a director of four other customers and a shareholder in two more. A trigger should fan out along the relationship graph and open cases on every connected record.

Ownership works the same way. Under the widely applied fifty percent aggregation principle, an entity owned in aggregate by designated persons is treated as blocked even when it is not itself listed. One designation can change the status of a whole chain of subsidiaries. Read up on the 50 percent rule in sanctions screening before designing the propagation logic.

De-duplicate and let triggers decay

The same underlying change often arrives from several feeds. Group events by customer and change type inside a short window, then open one case with several evidence items attached. Set a decay rule too, so an assessed trigger does not reopen every time the source republishes the record. Document the suppression logic. Undocumented suppression looks like a cover up when an examiner finds it.

What the review record has to show

An examiner will ask you to walk one trigger end to end. The file should answer without narration.

What changed, with the old value and the new value side by side.
Which source detected it, on what date, and when the change actually occurred.
Which rule classified it, and at what response level.
What was checked, collected and screened.
Whether the risk rating moved, and the reasoning either way.
Who approved the outcome, at what seniority, and when.
Whether a suspicious activity report or a sanctions notification was considered.

Keep the screening evidence in a form you can reproduce, meaning the list versions used, the search terms, the match scores and the disposition notes. Our guidance on record keeping for denied party screening covers the fields that survive an audit, and the same discipline works for AML triggers. Where a match is dismissed, the reasoning has to be specific enough for a reviewer to reach the same answer alone.

Running triggers alongside a periodic cycle

Few firms go straight from calendar reviews to a fully event driven model. Run both for a period, then compare. For each periodic review completed during the parallel run, ask whether a trigger had already caught what the review found. Where triggers caught everything, the periodic review added nothing. Where the review found something no trigger saw, you have located a missing rule or feed. That gap analysis is the evidence you need before shortening a cycle.

Keep a backstop review after the transition. A long outer interval catches slow drift that no single event would flag, such as a business that changed gradually over years. Deciding how often to screen suppliers and customers follows the same reasoning, so set both schedules together.

Triggers only work if the baseline was right on day one. Weak sanctions screening in customer onboarding produces a file that is wrong from the start, and no amount of event monitoring repairs it.

Key takeaways

A trigger is a material change that could alter the risk rating or invalidate part of the customer file, and materiality must be defined in policy.
FATF Recommendation 10 requires customer information to be kept current on a risk sensitive basis, and the EU Anti Money Laundering Regulation sets maximum update intervals of one year for higher risk customers and five years for others from 10 July 2027.
Every trigger needs four attributes before it becomes a control: a detection source, a default response level, a named owner and a deadline. Amendments to existing list entries count as triggers too.
A broken data feed produces zero alerts, which is indistinguishable from a clean book, so feed heartbeats and canary records belong inside the control.
Record both the date the change occurred and the date you detected it, since the gap is the first thing an examiner will question.

Frequently asked questions

What is an event driven KYC review?

It is a customer due diligence review that starts because a defined change occurred, rather than because a scheduled date arrived. The change is called a trigger. Typical triggers include sanctions designations, ownership changes, adverse media, jurisdiction moves and transaction behaviour outside the expected profile. The review is sized to the change, so a minor update may need only a targeted check.

Does event driven review replace periodic review?

Not entirely, and regulators generally expect both. Event driven review catches discrete changes quickly. A long backstop interval catches slow drift no single event would flag. Most firms run the two in parallel first, compare what each catches, then extend the periodic interval where triggers demonstrably caught everything.

How quickly must a trigger be actioned?

It depends on the trigger. Sanctions matches must be handled immediately, because the prohibition applies from the moment a designation takes effect. Ownership changes and adverse media are commonly given five to fifteen business days. Documentary triggers such as an expired passport usually run on a thirty day clock. Set the clocks in policy and report breaches.

How do you stop a trigger engine producing too many alerts?

Grade the response instead of running one review type. Most events should end at logged or targeted check. Only a minority need a full refresh. Calibrate thresholds by replaying historical changes against draft rules and counting how many would have altered a rating. Group duplicate events from multiple feeds into one case, and document any suppression logic.

Do trade compliance events count as KYC triggers?

They should, if you move goods. A consignee appearing on an entity list, a change in the goods shipped, a new freight forwarder or a rule change that brings your products into licence scope all affect risk. Most published AML trigger lists ignore these. Exporters are safer treating trade control and AML events as one combined set.

Getting the screening layer right

Screening fires the most urgent triggers, so test it first. You can run a denied party screening check against consolidated government lists before committing to a full trigger build. Globalior’s free screening tool is a reasonable place to sanity check a sample of names and spot the ones that will generate noise.

For a second opinion on your trigger list, your thresholds or how your feeds are wired, get in touch with the Globalior team.