We run periodic updation backlogs down for NBFCs whose books went past the Reserve Bank of India's re-KYC timeline. The work is segmentation of the overdue population, a channel strategy matched to each segment, the engineering to make low-friction updation possible, and a dated per-customer evidence trail showing what was attempted and when.
This is a backlog problem, not an onboarding problem
Everything about remediation differs from new customer acquisition, and teams that staff it like onboarding work get poor results.
In onboarding, the customer is present, motivated and already in a flow. They want the loan; completing verification is the price of getting it. In remediation, the customer is not present. They have the product already. Nothing they want depends on responding to you. The entire problem is getting a non-motivated person to complete a task that benefits them only indirectly, at a moment they did not choose.
The population is also different in kind. An overdue book is not a queue of identical items. It contains customers whose details have not changed and who are reachable in thirty seconds, customers whose registered mobile number stopped working years ago, customers whose documents have expired, customers who have effectively stopped using the product, and customers who are in the book twice under slightly different spellings. Treating those as one workstream is the single most common reason a remediation programme stalls after the easy third.
And the deadline has already passed. The Reserve Bank of India's timeline for periodic updation of low-risk customers ran to 30 June 2026. Content written for lenders preparing to meet it is no longer the situation most books are in. What matters now is the rate at which the remaining population is being cleared, and whether that work is evidenced.
What the programme covers
- Segmentation of the overdue book by reachability, by whether details have changed, by product activity and by risk category, because each segment needs a different channel and a different message.
- Channel strategy per segment — the reachable-and-unchanged segment can often be cleared through a self-service confirmation; the stale-contact segment needs a different approach entirely and will not respond to more email.
- Low-friction updation engineering. The reason many customers abandon is not unwillingness; it is a flow that asks for a document upload on a phone at the wrong moment. Reducing the number of steps between the message and the completed updation moves completion rates more than any amount of resending.
- An evidence trail per customer, dated, recording each attempt, the channel used and the outcome, retained on your systems and queryable by account.
- A defined end state for non-responders, designed with your compliance team, so accounts do not sit in a pending status indefinitely with nobody owning the decision.
- Progress reporting that shows the composition of what remains rather than only a total, because a shrinking backlog made entirely of unreachable customers needs a different intervention from a shrinking one that does not.
How the work runs
The first phase is diagnostic and it is mostly data work. We take the overdue population and characterise it: how many are contactable through a channel that still works, how many have changed address or documents, how many are dormant, how many are duplicates of each other. Almost every book we have looked at contains a meaningful segment that can be cleared with far less friction than the rest, and finding it first changes the shape of everything after.
The second phase is building the path. This is where the engineering sits — the updation flow itself, the deep links that drop a customer into the right step rather than a login page, the pre-filling of what you already hold so the customer is confirming rather than re-entering, and the logging that turns each interaction into evidence.
The third phase is the campaign, run by segment rather than all at once, with the approach adjusted based on what the first waves reveal. Response behaviour is rarely what anyone predicts in advance, and a programme that cannot adapt after the first wave wastes its remaining attempts.
The fourth phase is the tail, and it is the one that gets under-resourced. The last portion of any backlog is the hardest — unreachable customers, disputed records, accounts that need a decision rather than a contact attempt. Planning for it from the start avoids the pattern where a programme reports strong early progress and then stops.
Evidence, and why it is the deliverable that matters
If the backlog could be cleared completely, evidence would be a formality. Backlogs are rarely cleared completely, which makes the record of effort the part that carries the weight.
The distinction that matters is between aggregate and per-account. A report stating that a large number of communications were sent is an aggregate. It does not answer the question actually asked in a supervisory conversation, which is about one specific customer: what did you do about this account, when, and what happened. Answering that requires a dated per-customer record, held by you, not a CSV export from a messaging vendor with thirty days of retention.
We build that record as part of the flow rather than reconstructing it afterwards, because reconstruction after the fact is both expensive and less credible.
Regulatory context
The requirement for periodic updation of KYC records sits in the Reserve Bank of India's Master Direction on Know Your Customer, available at rbi.org.in. Read the current text directly. The periodicity differs by customer risk categorisation, and the procedure differs depending on whether the customer's details have changed — a distinction that materially affects how much friction a given segment needs to be put through, and one that is routinely flattened in secondary summaries.
We do not publish an interpretation of what your exposure is or a figure attached to it. What we do is build the programme so the answer to a supervisory question is a query rather than a project.
Where this sits alongside the rest
Remediation frequently surfaces problems in the onboarding flow that created the book, because records that were captured without validation years ago are exactly the records that are hardest to update now. Where that is the case, fixing the intake so the next backlog is smaller is KYC API integration work, and it is worth scoping the two together.
Where the remediation channel needs a regulator-prescribed live process rather than a self-service confirmation, that is Video KYC and V-CIP.