Perpetual KYC: keeping customer records current without re-onboarding everyone

Perpetual KYC means refreshing a customer's record when something changes, instead of re-checking everyone on a calendar. A sanctions list update, an expiring passport, a sudden change in how an account is used or a new director at a business customer each triggers a targeted refresh of the part of the record it affects. Customers whose risk and circumstances have not changed are left alone.

This is what the FATF standard already asks for. It requires firms to keep customer due diligence (CDD) data up to date by reviewing existing records, "particularly for higher-risk categories of customers", and it allows less frequent updates for lower-risk customers. A campaign that re-onboards the whole book spends effort on customers where nothing changed, while the customer who changed last month waits for their turn.

What does the FATF standard actually require?

Three passages in the FATF Recommendations (opens in a new tab) (updated October 2025) set the frame.

• Ongoing due diligence. Recommendation 10(d) requires scrutiny of transactions throughout the relationship to ensure they are "consistent with the institution's knowledge of the customer, their business and risk profile, including, where necessary, the source of funds".

• Keeping data current. Paragraph 23 of the Interpretive Note to Recommendation 10 requires that CDD information "is kept up-to-date and relevant by undertaking reviews of existing records, particularly for higher-risk categories of customers".

• Scaling by risk. Paragraph 20 gives "updating more regularly the identification data of customer and beneficial owner" as an example of enhanced CDD. Paragraph 21 gives "reducing the frequency of customer identification updates" as an example of simplified CDD for lower risk, adding that simplified measures are not acceptable where there is suspicion.

The FATF's risk-based approach guidance for the banking sector (opens in a new tab) (October 2014) is more concrete. It says monitoring involves "identifying changes to the customer profile" and keeping it up to date, "which may require the application of new, or additional, CDD measures". It says monitoring "should be carried out on a continuous basis or triggered by specific transactions", that banks should adjust its extent to customer risk, and that the criteria for doing so should be documented.

Some national rules add fixed review periods on top. Those still apply; perpetual KYC changes what happens between them. Requirements differ by jurisdiction, and this article is general information, not legal advice.

Which events should trigger a refresh?

Start from a list of events and, for each, decide what part of the record it makes stale. That is the core design decision.

Two principles follow from the table. First, most events need a small, specific answer, not a full re-onboarding. Second, the customer should only be asked for what changed. Re-asking a customer for everything they supplied last year adds friction without adding information.

How often should a quiet customer be reviewed?

Events will not catch everything, so keep a backstop review date, scaled by risk. The standard gives you room to set lower-risk dates further out and higher-risk dates closer in, as long as the criteria are documented. For example, an illustrative policy might set review dates by risk tier, pull a review forward when an identity document expires before that date, and reset the clock whenever a full verification is completed.

The backstop review should be light by default. For a lower-risk customer it might be a questionnaire confirming occupation and expected activity, plus a contact check. A full identity verification is reserved for when something about the identity itself is in doubt.

A worked example: one customer, a year of events

An illustrative lender in Accra onboards a salaried customer with a verified Ghana Card, a clear screening result and a stated monthly volume.

• Month 3. A sanctions list update. The customer is re-screened automatically. No match; nothing is asked of the customer.

• Month 5. The customer changes their phone number in the app. A one-time code confirms the new number. The identity record is not touched.

• Month 8. Monthly inflows jump to several times the declared volume, from many new senders. Monitoring raises an alert. The lender asks for an updated source-of-funds declaration; the customer explains a new side business, and the analyst records it and updates the profile.

• Month 11. A login from a new device in another country is followed by an attempt to add a new payee. The lender asks for a selfie re-verification before releasing the payment.

• Month 12. The backstop review date arrives. Because the record was refreshed in months 5 and 8, the review confirms the remaining fields and closes.

At no point did the customer re-onboard. Every refresh was triggered, proportionate and recorded.

What does a good refresh system need?

• A single customer record that each refresh updates, rather than a new record per check.

• History that survives. What you found before is evidence. A refresh should add to the record, not overwrite what the earlier check established.

• Locked facts. Identity data established by a verification should only change through another verification, never through a free-text edit.

• Partial requests. The ability to ask for one document, one declaration or one selfie.

• Signals that arrive on their own: re-screening results, due dates, monitoring alerts, rather than analysts polling for them.

Where does Myaza Trust help?

Several of these pieces are available as parts of Watchlist Screening, Workflows and our AML monitoring tools.

• Ongoing screening. Customers enrolled in screening are re-screened for sanctions, PEP and adverse media on a risk-based schedule, and a workflow's Ongoing monitoring setting decides whether enrolment keeps re-screening or runs once (screening documentation).

• Due dates as events. An entity.reverification_due webhook fires when a customer's renewal is due, with the due date, so your system can start a refresh (webhooks).

• Light refresh flows. Workflow templates include Re-verification for customers due for renewal, and scoped flows such as Declarations refresh (a questionnaire alone) and Contact re-verification (one-time codes to the email and phone on file). Scoped flows land on the existing customer record without touching its KYC status (workflows documentation).

• Redo only what changed. The Verify again API asks a customer to redo a finished verification, optionally only specific steps such as the document or the selfie. The verification keeps its ID and the earlier attempt is kept.

• Step-up re-verification. A hosted re-verification link for an individual can be triggered by a workflow, the API or the dashboard when activity raises doubt about who is acting.

• Locked identity facts. On a customer we verified, identity fields cannot be edited; a new verification is the route to change them (Identity Hub).

The policy decisions stay yours: which events matter, which review dates apply to which risk tiers, and what counts as a satisfactory answer.

Your perpetual KYC starting checklist

• List the events that make each part of a customer record stale, and the smallest response to each.

• Set backstop review dates by risk tier and write down the criteria.

• Make sure each refresh updates one record and keeps the history.

• Ask customers only for what changed.

• Move re-screening, due dates and monitoring alerts from manual checks to events your systems receive.