KYC reverification is not a single annual task. It is a risk-based process for deciding when customer identity data is no longer reliable, complete, or appropriate for the account’s current activity. This checklist explains the main KYC review triggers, how to choose a review response, what evidence to retain, and when to update the process as regulations, markets, and verification tools change.
Overview
Initial identity verification establishes a customer’s identity at onboarding. Ongoing customer due diligence tests whether the information supporting that decision remains accurate and whether the customer’s behavior or risk profile has changed. Reverification may range from a sanctions and watchlist rescreen to a complete identity refresh with a new document and selfie or biometric check.
The correct response depends on the trigger, the customer’s risk tier, the information that changed, and the rules that apply to your product and jurisdiction. A low-risk profile with an unchanged document may only need a data confirmation. A high-risk account, an expired identity document, or a material change in ownership may require enhanced review and temporary restrictions until the review is complete.
Do not treat a calendar schedule as a substitute for event-driven monitoring. A useful KYC verification platform combines scheduled reviews with triggers from account activity, identity data, sanctions screening, fraud signals, and support interactions. Document the reason for each review so an auditor or internal reviewer can understand why the action was proportionate.
Core KYC reverification checklist
- Define customer risk tiers and the review cadence assigned to each tier.
- List event-driven triggers that require an immediate review or rescreen.
- Specify which fields, documents, and beneficial-owner details must be refreshed.
- Set clear outcomes: pass, request more information, restrict activity, escalate, or exit.
- Record the trigger, decision, evidence, reviewer, timestamps, and customer communications.
- Review retention, access, deletion, and biometric-data handling requirements before storing new evidence.
Checklist by scenario
Use the following scenarios as a starting point for a decision matrix. Your compliance owner should map each one to the requirements of the products and jurisdictions you actually serve.
| Trigger | Initial response | Possible next step |
|---|---|---|
| Scheduled periodic review | Confirm risk tier, customer details, document status, and recent activity. | Refresh selected fields or run full reverification according to risk. |
| Identity document expired, lost, revoked, or near expiry | Check the document’s type, issuing jurisdiction, validity, and replacement status. | Request a current document and use document verification software where appropriate. |
| Material customer-data change | Compare the requested change with existing records and account behavior. | Verify the changed field and consider a broader review if the change affects risk. |
| Suspicious activity or fraud signal | Preserve relevant evidence and route the case to trained reviewers. | Apply proportionate controls, conduct enhanced due diligence, and follow reporting procedures where applicable. |
| Risk-score or customer-segment change | Identify which signal caused the change and whether it is reliable. | Move the customer to the appropriate cadence or request additional evidence. |
| Sanctions, politically exposed person, or adverse-information alert | Resolve potential matches using approved review procedures; do not rely on a name match alone. | Escalate confirmed or unresolved matches according to policy and applicable obligations. |
| Account recovery, credential reset, or high-risk profile change | Authenticate the requester using independent signals and inspect recent access events. | Require step-up identity proofing before restoring access or changing critical data. |
| New product, geography, payment method, or transaction pattern | Assess whether the new use changes the customer’s risk or due-diligence requirements. | Refresh identity data, source-of-funds information, or business details as needed. |
Suggested review cadence
A cadence should be a control, not an assumption that every customer needs the same treatment. For example, a program may review lower-risk customers less frequently, review standard-risk customers on a regular cycle, and review higher-risk customers more often or through continuous monitoring. The exact intervals should come from your documented risk assessment and applicable requirements rather than a generic industry timetable.
- Lower risk: use scheduled data confirmation and event-driven review, with full reverification when a trigger warrants it.
- Standard risk: combine a defined periodic KYC review with sanctions rescreening and monitoring for material changes.
- Higher risk: use a shorter, documented review cycle, stronger evidence requirements, and senior or specialist escalation where required.
- Business accounts: reassess the legal entity, registration details, beneficial owners, controllers, and authorized users. See the KYB verification guide for a related checklist.
Customer-notification template
Keep messages specific without revealing sensitive detection logic. A practical notice can read:
“We need to update information associated with your account. Please complete the requested verification by [date] using the secure link in your account. We may ask you to confirm personal or business details and provide a current identity document. We will not ask for your password or one-time authentication code by email. If you need help or cannot complete the process, contact support through [approved channel].”
Offer an accessible fallback for customers who cannot use the primary flow, and define what happens if the deadline passes. Avoid collecting documents through unapproved email or chat channels.
What to double-check
Evidence and decision records
For each review, retain enough evidence to reconstruct the decision without keeping unnecessary personal data. The record should normally identify:
- The trigger and date it occurred.
- The customer risk tier and the rules or policy applied.
- Data and documents reviewed, including validity and issuing context.
- Verification results, match-resolution notes, and relevant fraud or access signals.
- The outcome, restrictions, escalation path, and reviewer approval.
- Customer notices, deadlines, failed attempts, and any approved exception.
Store sensitive evidence in a controlled system rather than scattered operational folders. If your workflow uses a secure credential vault or identity platform, check encryption, role-based access, audit logs, retention controls, and deletion behavior. For biometric checks, confirm that the workflow collects only what the approved purpose requires and that fallback paths are documented. The secure credential vault architecture guide provides useful design considerations.
Verification quality and integrations
Review false positives before imposing restrictions. A name-screening alert, document mismatch, or face verification failure may require manual resolution rather than automatic rejection. Test how your identity verification software handles retries, partial completion, duplicate accounts, expired documents, and vendor outages. If you use a face verification API or liveness detection software, confirm that failure messages do not disclose unnecessary security details and that an accessible fallback exists. For related QA considerations, see the liveness detection testing checklist.
Also verify that identity records remain consistent across onboarding, account access, payments, case management, and reporting systems. Changes made in one system should not silently create conflicting customer profiles. When authentication or account recovery is involved, validate token claims, session controls, and OAuth or OIDC integration behavior before treating a successful login as proof of identity.
Common mistakes
- Using one review date for everyone: A fixed annual campaign can create unnecessary friction for low-risk customers while missing event-driven risk.
- Rechecking without a decision rule: Collecting a new document is not enough. Define what each result means and who can approve an exception.
- Ignoring document context: A document may be authentic but unsuitable for the customer’s jurisdiction, product, or current circumstances.
- Over-collecting data: Request only evidence connected to a stated verification purpose, and set deletion or retention rules before collection.
- Automating every adverse result: Give trained reviewers a path to resolve transliteration differences, common names, technical failures, and accessibility issues.
- Failing to protect recovery flows: Account recovery can be a high-impact identity event. Treat changes to email, phone, credentials, and payout details as risk signals.
- Leaving exceptions undocumented: A manual override should include its reason, authority, compensating controls, expiry, and follow-up owner.
- Letting vendor changes break continuity: Before migrating verification providers, map stored evidence, decision history, webhooks, retry behavior, and data deletion. Use the KYC platform migration runbook as a planning reference.
When to revisit
Revisit this KYC reverification checklist before seasonal planning cycles, when workflows or tools change, and whenever your business enters a new market or launches a materially different product. It is also useful during quarterly compliance reviews, audit preparation, incident investigations, and analysis of stale or incomplete identity records.
At each review, confirm five inputs: the jurisdictions served, applicable regulatory expectations, document-validity rules, sanctions-screening configuration, and capabilities of the identity verification software. Then test a sample of cases across pass, fail, manual review, exception, and account-recovery paths. Compare the written policy with what the product actually does.
Finish with an owner and a dated action list. Update risk tiers, cadence rules, customer notices, evidence fields, escalation thresholds, and retention settings only after the change has been reviewed and approved. If the change affects integrations, run end-to-end tests in a controlled environment and monitor the first production cases. This keeps customer identity refreshes proportionate, explainable, and ready for the next policy or workflow change.
For a broader control review, pair this article with the digital identity verification compliance checklist and the false-positive review queue playbook.
