KYC and AML get tested together so often that KYC rarely gets a UAT plan of its own. The transaction-monitoring rules get the attention because that's where the regulatory penalties make headlines. But KYC has its own UAT surface — onboarding, periodic updation, video-based verification, and deduplication against the Central KYC Registry — and most of it is not covered by an AML test plan at all, because it happens before a transaction ever occurs.
Periodic Re-KYC: Three Risk Tiers, Three Different Clocks
Under RBI's KYC Master Direction, periodic re-KYC runs on a risk-based clock: at least once every two years for high-risk customers, once every eight years for medium-risk, and once every ten years for low-risk. A UAT plan that tests "the system flags an account when re-KYC is due" against one risk tier and assumes the others behave the same way has not tested the actual rule — three different tiers means three different trigger dates need independent verification, not one date with a label changed.
RBI's June 2025 update added a relief provision specifically for low-risk customers: accounts must continue operating normally even past the due date, with banks required to complete the update within one year of the due date or by 30 June 2026, whichever is later. A test plan written before this update — or one that still treats every overdue re-KYC the same way regardless of risk tier — will incorrectly restrict a low-risk account that the current rule says should keep functioning.
Re-KYC due-date computation independently verified for each risk tier (2/8/10 year clocks). Low-risk grace-period handling — account remains fully operational past the nominal due date per the relief provision. Risk-tier reclassification mid-cycle — verifying the re-KYC clock resets correctly when a customer's risk category changes.
The Partial Freeze Sequence Has Two Stages, Not One
When a customer does not respond to a re-KYC request, the account does not simply get blocked. The actual sequence is: at least three months' advance notice to the customer, then — if still non-compliant — a partial freeze that allows credits but blocks debits, followed by a full freeze (no credits or debits) if non-compliance continues for a further six months. A test case that verifies "account gets frozen" without testing the partial-freeze stage, the credit-allowed/debit-blocked distinction, and the specific timing between stages has tested an outcome, not the actual regulatory sequence — and the partial-freeze stage is exactly the one most likely to be implemented incorrectly, since it requires the system to apply two different rules to the same account simultaneously.
Systems that implement freezing as a single account-status flag (active/frozen) cannot represent the partial-freeze state correctly. If your core system only has a binary freeze flag, that is a UAT finding worth raising before go-live, not after a customer complains that a should-be-frozen account is still accepting debits.
Video KYC: The Edge Cases Are in the Liveness Check, Not the Upload
Video-based Customer Identification Process (V-CIP) testing tends to focus on the straightforward path — customer joins the call, shows the document, system captures the photo, account opens. The scenarios that actually fail in production are at the edges: poor lighting or connectivity causing a liveness check to time out mid-session, a customer using a document that does not match the declared details exactly (a maiden name on an old document, for instance), or a session that disconnects after identity capture but before the final confirmation step. A UAT plan needs explicit scenarios for session interruption and resume behaviour, not just the clean end-to-end happy path.
CKYCR: Deduplication Logic Is the Test That Gets Skipped
The Central KYC Registry exists so a customer's verified KYC record can be reused across institutions instead of re-verified every time. The functional requirement that gets tested is usually "system submits KYC data to CKYCR and retrieves a KYC Identifier." What gets skipped is the deduplication scenario — what the system does when a CKYCR lookup returns a match against an existing record with slightly different data (a changed address, a different spelling of the same name). A system that creates a duplicate record instead of triggering an update-or-flag workflow defeats the entire purpose of having a central registry, and this is precisely the scenario most UAT plans never construct, because it requires deliberately testing with a customer who has a prior, slightly-inconsistent CKYCR record — not a fresh one.
For corporate and partnership customers, beneficial ownership identification thresholds have been revised — partnership firms now use a lower 10% threshold (down from 15%) for determining who must be identified as a beneficial owner. A UAT plan still testing against the older threshold will pass cases that should fail under current rules.