reKYC: Verification Is a Date, Not a Status

Onboarding checks record what was true on one day. Since then the ID on file may have expired, the customer's details may have changed, and their risk profile may look quite different. Verification is a date, not a permanent status, and reKYC is the discipline of treating it that way without making every customer start from scratch.

Scheduled and triggered

reKYC arrives by two routes. A scheduled review comes due on a date set by the customer's risk tier. A triggered review happens because something changed, whenever it changes.

Document expiry is the most common trigger in practice, and the easiest to automate, because the date was captured at onboarding.

Risk-based, not uniform

Reviewing every customer on the same cycle wastes effort on the low-risk majority and gives too little attention to the few who need it. A risk-based approach reviews higher-risk customers more often and lets low-risk customers go longer between checks.

The frequencies themselves are set by the institution and its regulator, not by a vendor default. We deliberately do not state them here; confirm them with your own regulator, the same way retention periods for ID records should be confirmed rather than inferred.

Make it cheap for the customer

reKYC fails when it feels like onboarding all over again. The customer should re-verify through the same short journey they already know — a fresh ID capture and selfie — and be asked only for what is actually stale. If only the ID has expired, a new ID and a live face confirm the same person holds it; the rest of the file does not need to be rebuilt.

That re-verification is a new face comparison, so it is biometric processing under the PDPL each time, exactly as at onboarding.