Skip to main content
DoneThat

AI Adoption GuideBankingReview

Perpetual KYC refresh

ML monitors transaction and event signals to trigger CDD refresh only when a customer's risk profile changes materially, replacing calendar-based reviews.

Banking processAcquireOnboardOpenFundTransactServiceReviewClose

By Don, DoneThat’s AI coach · updated

A due date is a weak reason to open a file

Periodic KYC treats the calendar as the risk event. Twelve months elapse, a queue fills, and CDD works a file that may be unchanged since the last review. The customer whose profile actually moved (new counterparties, a beneficial-owner update, screening or media that was not on the last pack) waited for an anniversary.

Perpetual KYC inverts the trigger. Models watch transaction and event signals and open a CDD refresh only when the customer's risk profile looks materially different from the last completed file. The quality outcome is a triggered refresh with a cite of what changed, still completed by CDD. It is not a model score, a new rating, or a closed alert.

Calendar work does not vanish. If policy still requires a high-risk periodic review on a fixed cycle, that review stays scheduled. Event-driven refreshes sit beside it and can feed the same narrative, including through annual review document generation. Treating pKYC as permission to skip those high-risk files is a control failure.

Watch material-change signals, not every payment

Material change is a judgement CDD already makes at refresh. Monitoring should surface the same kinds of facts earlier, with enough context that an analyst can see why the file opened. The materiality bar belongs in KYC policy, not in a vendor default.

Watch signals that alter who the customer is, what they do, or who they are connected to:

  • Transaction behaviour that does not match expected activity from onboarding or the last completed CDD: new corridors, a product they barely used, counterparties outside the stated business.
  • Network structure that belongs in a KYC conversation, not only in a SAR debate. Use the same family of evidence as AML transaction network monitoring, here as a reason to reopen the file rather than as a suspicious-activity decision.
  • Screening and news events that are new relative to the last pack: ownership changes, adverse media not previously assessed. Tie this to adverse media continuous monitoring so a media event becomes a cite, not a second unexplained queue.
  • Core relationship events: new products, new authorised signers, a change in legal form, dormant-to-active behaviour.

Cluster related events into one cite before a task is created. Ten payments to the same new corridor are one change, not ten refreshes.

Do not open a refresh on every small payment. A low-value card spend in a new merchant category, a single transfer below the customer's usual ticket, or a one-off inbound from a known payroll source is not a material change. If every model anomaly opens a file, the KYC queue becomes a transaction-monitoring clone sitting on the wrong team.

Transaction monitoring, screening, and core platforms (NICE Actimize, Dow Jones, Temenos among them) already emit many of these events. The perpetual-KYC control is the policy that decides which events are material enough to open CDD work. Those systems are not a new source of truth for the customer's risk rating.

Open a refresh with a cite

When a signal crosses the material-change bar, open a refresh task. Do not invent a risk rating. The rating on the last completed CDD stays until a person finishes the file and, where policy requires it, second line agrees.

The task needs a cite a reviewer can audit:

  • What was observed, in business language (the event or pattern).
  • Over what window, compared with what baseline (last completed CDD, expected activity, prior screening state).
  • Why the bank's KYC procedures treat that as material, not only a model score.
  • What CDD is asked to confirm or collect.

Put the cite on the KYC case, not only in a model log. If transaction monitoring already opened a case on the same activity, attach that reference so CDD is not rediscovering the payments.

Illustrative path: a corporate current-account customer has used a stable set of domestic suppliers. Over several weeks, outbound payments cluster toward new counterparties in a corridor that never appeared in the business description, at tickets well above the customer's usual pattern, with no invoice trail on the file. The right output is one refresh that cites the corridor, the counterparties, the comparison to the last expected-activity statement, and the documents to request. The wrong outputs are an automatic high-risk stamp, a closed alert labelled refreshed, or a separate task for every payment in the cluster.

If you use orchestration to assemble packs or sequence checks, keep it as workflow around the cite. Agentic KYC orchestration can fetch documents and pre-fill a pack. It cannot complete CDD, and it cannot close the trigger as done.

CDD completes the file

A trigger is a reason to look. It is not a completed refresh. The file is done when CDD has reviewed the cite, collected or confirmed what the procedure requires, recorded the decision (including no change to rating when that is the honest outcome), and stored the evidence.

The analyst can disagree with the trigger. Models will over-fire. Closing the task as not material, with a short rationale that the file is unchanged, is a valid completion. Deleting the task because the model was noisy is not.

Evidence from screening, media, and transactions belongs on the refresh. Parallel closed alerts with no KYC decision leave a gap that looks clean in operations and fails in testing.

High-risk customers keep their calendar review even if event-driven refreshes landed in the same year. Event work can feed that periodic pack so CDD is not rewriting the same narrative twice. It does not replace the periodic control unless the policy owner has rewritten the standard and second line has agreed how it will be tested.

Residual risk stays a human conclusion. Models may rank which files to open first. They do not write the rating that goes on the core record.

Second line should sample two populations: refreshes that completed with a change, and triggers closed as not material. Ask whether the cite was understandable, whether CDD actually worked the file, and whether any high-risk periodic review was skipped because an event task existed.

Three production failures that look like progress

Dropping the annual review for high-risk. Periodic review for high-risk customers is often a policy and regulatory expectation. Event-driven refresh can replace calendars only where the policy says it may, and typically not for that segment. Leave the high-risk cycle intact until the standard has been changed in writing.

Triggering on every small payment. If the feature is anomaly-on-transaction, operations inherit a TM queue with KYC titles. Tighten to material change against expected activity, cluster related events into one cite, and put a rules or human gate in front of task creation.

Closing the trigger as if the file were refreshed. Green dashboards on dispositioned alerts are not KYC quality. Completion is a CDD file with the cite, the work done, and the decision. A pack of gathered documents is still incomplete until an analyst signs it.

A related error is using the trigger to overwrite the risk rating. The cite explains why CDD should look. CDD writes the rating.

Keep the operating picture testable. Material-change monitoring opens work. CDD completes work. Calendar reviews that policy still requires still run.

Is this worth automating for you?

Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other. This one is rated high effort to implement, so the baseline matters more than usual.

DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.

Measure the baseline first