Re-KYC is the repeat verification of an existing customer when the relationship changes or the customer must be reviewed again on a schedule. It matters because identity and risk are not static, and the control only works if the bank can trigger, log, and act on those changes consistently.
Expanded Definition
Re-KYC is the repeat verification of an existing customer when new risk signals emerge, the relationship changes, or policy requires a periodic review. In practice, it sits between initial onboarding and ongoing monitoring, making it a lifecycle control rather than a one-time checkbox. For banks and regulated fintechs, Re-KYC is used to confirm that identity evidence, beneficial ownership, transaction patterns, and expected account use still match the customer profile. Industry usage is still evolving, so some organisations treat Re-KYC as a scheduled refresh while others trigger it only on events such as adverse media, address changes, ownership changes, or unusual activity.
That distinction matters because strong Re-KYC should produce an auditable decision trail, not just a renewed form. Guidance from the FATF Recommendations — AML and KYC Framework supports this broader, risk-based approach, while digital identity assurance trends in eIDAS 2.0 — EU Digital Identity Framework reinforce the need to re-check identity evidence when trust conditions change. The most common misapplication is treating Re-KYC as a calendar-only form refresh, which occurs when institutions ignore event-driven risk changes and fail to document why a customer was reverified.
Examples and Use Cases
Implementing Re-KYC rigorously often introduces review friction for customers and operations teams, requiring organisations to weigh stronger assurance against slower service and higher manual effort.
- A retail bank flags a corporate customer for Re-KYC after a beneficial ownership change, then validates the updated owners before allowing continued cash management access.
- A fintech reopens customer review when transaction volume jumps sharply, using the case to confirm source of funds and expected activity.
- A payments provider performs scheduled Re-KYC for dormant accounts before reactivation, reducing the chance that old profile data drives new risk decisions.
- A compliance team uses adverse media and sanctions-screening hits to trigger Re-KYC and decide whether to retain, restrict, or exit the relationship.
For operational context, NHI Management Group’s Ultimate Guide to NHIs is useful because many institutions now apply similar lifecycle thinking to service accounts and API credentials. Re-KYC also benefits from the identity assurance logic expressed in the FATF Recommendations — AML and KYC Framework, which emphasize risk-based, ongoing due diligence rather than static onboarding alone.
Why It Matters in NHI Security
Re-KYC matters in NHI security because the same control mindset applies to machine identities, third-party access, and delegated authority. When organisations fail to reverify relationships, they often keep outdated trust assumptions alive long after the underlying risk has changed. That creates blind spots in access approvals, monitoring thresholds, and escalation paths, especially when account ownership, business purpose, or external dependencies shift without review. NHI Management Group’s Ultimate Guide to NHIs notes that 68% of organisations do not know how to fully address NHI risks, which is a reminder that lifecycle controls fail when verification is treated as a one-off event instead of a recurring governance process.
For human and machine identity programs alike, the lesson is the same: if the record is never refreshed, the control eventually protects only history, not reality. Organisations typically encounter account abuse, failed audits, or suspicious payment activity only after a relationship has drifted or been compromised, at which point Re-KYC becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0, NIST SP 800-63 and NIST AI RMF set the technical controls, and NIS2 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Lifecycle review and revalidation map to NHI governance and identity assurance expectations. |
| NIST CSF 2.0 | GV.RM-06 | Risk management decisions require recurring review as conditions and exposures change. |
| NIST SP 800-63 | IAL2 | Identity evidence must be sufficiently strong for the assurance level used in repeated verification. |
| NIST AI RMF | GOVERN | Ongoing oversight and traceability are central to managing changing risk conditions. |
| NIS2 | Ongoing security governance supports continuous trust and review across critical business processes. |
Reassess customer risk on a set cadence and after material events, then document the resulting action.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
