Perpetual KYC replaces the fixed-calendar review with an event-driven one. Instead of refreshing every customer on a one, three, or five-year cycle, you watch a stream of signals about each customer and open a review only when something material changes. The clock still exists as a long-stop, but most work is now triggered by evidence rather than by a date.
Periodic review is a backlog machine for a simple reason: it schedules effort against time instead of against risk. A customer who has not transacted in eighteen months and whose details are unchanged gets the same review slot as one who just registered a new beneficial owner in a sanctioned jurisdiction. The queue fills with the former, and the analysts who should be looking at the latter spend their day clearing calendar-driven tickets that mostly resolve to “no change.” Quarter-end makes it worse, because refresh dates cluster and the backlog spikes exactly when the rest of financial crime operations is busy.
What actually counts as an event
The whole model depends on defining the trigger set well, and this is where most implementations are too coarse or too noisy. An event is a change in the world that could move a customer’s risk rating. It comes from one of a few places:
- Internal behaviour: a step change in transaction volume or value, a new counterparty geography, a product upgrade, a dormant account waking up, a change to a payment corridor.
- Static data changes: a new address, a director or shareholder change on a corporate customer, an updated beneficial ownership structure, an expired identity document.
- External signals: a sanctions-list update that now matches an entity, an adverse-media hit, a change in the risk score of a jurisdiction the customer operates in, litigation or insolvency filings.
Each of these needs a source system, a schema, and a defined latency. A sanctions delta should reach the trigger engine within hours; a media hit can tolerate a day. The engineering work is mostly plumbing and entity resolution: the transaction system, the CRM, the screening vendor, and the corporate registry all identify the same customer differently, and a trigger is worthless if it cannot be tied back to a single customer record with confidence. We treat entity resolution as the foundation here, not an afterthought, because a false link produces either a missed review or a review opened on the wrong party.
One rule we hold to: every trigger carries its evidence. The event records specifics. “Beneficial owner X was added on this date, from this registry filing, matching this record” is a trigger a reviewer can act on. “Risk may have changed” is not. Nobody should have to go find out why the ticket exists.
Point-in-time correctness and the audit trail
Perpetual KYC lives or dies on being able to reconstruct what you knew and when. A regulator asking about a customer in 2028 wants to see the state of that customer’s file as it stood on the day a decision was made, not as it stands today. That is a point-in-time correctness problem, and it is easy to get wrong if the customer record is a single mutable row that gets overwritten on every update.
We model the customer file as an append-only history. Every attribute has a valid-from and, where relevant, a valid-to. A risk rating is stored as a sequence of rated intervals, each carrying the evidence and the decision that produced it, rather than as a single field that gets overwritten. This gives you a few things periodic review never had:
- You can answer “what was this customer’s rating on the day of that transaction” without guessing.
- You can build eval sets from real history, replaying the trigger engine against past events to check that it would have fired when it should have.
- You avoid lookahead: when you test a risk-rating change, you feed the model only the data that existed at trigger time, not attributes that were added later.
Lineage matters as much as history. Each risk decision should link back through the trigger, the evidence, and the source system, so an examiner or an internal audit can walk the chain without reconstructing it from logs. When we build the feature store that feeds a risk model, every feature carries the as-of timestamp of the data it was computed from. Reconciliation against the source of truth runs on a schedule, because a feature store that quietly drifts from the transaction ledger will produce ratings you cannot defend.
Automation with a human path for real change
The point of all this is straight-through processing for the common case and human attention for the rare one. Most triggers resolve without a person: an expired document that the customer re-uploads, a volume spike that matches a known seasonal pattern, a media hit that entity resolution shows refers to a different person with a similar name. These close automatically, with the reasoning recorded.
The decisions we route to a human are the ones with real consequences. A downgrade in risk rating, as noted, always goes to a reviewer. So does any change that would move a customer across a regulatory boundary, such as into or out of enhanced due diligence. So does a trigger the model is not confident it resolved, which is why every automated decision emits a calibration score rather than a bare yes or no.
You control the review queue with a false-positive budget, the same way you would for transaction monitoring. If the trigger set generates more human reviews than the team can clear, it is not working, and the answer is to tighten trigger definitions and improve entity resolution rather than to raise thresholds blindly. We tune against a held-out set of past cases where the correct outcome is known, and we watch for drift: a corridor that was low-risk last year, a media source whose hit rate has changed, a model whose confidence has decayed as the customer base shifted. When the numbers move, the trigger set gets revisited. Perpetual KYC does not finish. Like any other control, it has to be maintained.
FAQ
How is perpetual KYC different from a shorter periodic review cycle?
Periodic review refreshes a customer on a fixed calendar regardless of whether anything changed. Perpetual KYC watches for events that change the risk picture and only opens a review when one fires, so effort follows actual change rather than the clock.
Does perpetual KYC remove the periodic review requirement entirely?
Not on its own. Most supervisors still expect a defensible refresh cadence for higher-risk customers, so we keep a long-stop timer that forces a review if no event has triggered one within the risk-band's maximum interval. The event stream shortens the average gap; the timer guarantees an upper bound.
What stops the model from silently downgrading a risky customer?
Risk-rating changes are asymmetric in our design. Upgrades to a higher risk band can be automated once evidence clears a threshold; downgrades always route to a human reviewer with the triggering evidence attached. The rationale and reviewer identity are written to the audit trail.