A borrower’s details change: what must loan management and servicing update?
A borrower detail change can leave loan systems out of step. See how an LMS should track verification, effective dates, downstream updates and open exceptions.
Suppose a borrower asks an NBFC to replace a mobile number. The service desk verifies the request and updates the customer record. The next day, a collections partner calls the old number from yesterday’s export.
Both teams can point to a completed task. The borrower still experiences a failed change.
In a Loan Management System (LMS), customer maintenance needs a completion rule that extends beyond saving a field. The LMS maintains the customer and loan records. Servicing must also track whether each affected destination has applied the approved change. That distinction becomes more consequential when a request changes identity information or a repayment bank account.
Start with what the field controls
Do not give every change the same risk treatment because the fields appear on the same screen. Ask what an incorrect change would allow, prevent or disclose.
| Change | Operating consequence | Question before completion |
|---|---|---|
| Contact number or email | Messages, authentication and agent contact may use it | Which uses are authorised, and which consumers still hold the previous value? |
| Name, address or identity information | Customer due diligence and documents may need review | What verification and registry work applies to this particular change? |
| Repayment bank details | Payment instructions and mandate records may diverge | Has the required payment arrangement actually become active? |
A common case-management process can coordinate these requests. It should not imply identical evidence requirements. A new phone number also should not become an automatic shortcut for approving a bank change submitted in the same interaction. The lender must define how the person and the authority for each action are established.
Start the CKYCR clock when updated information is obtained
Paragraph 63(7) of RBI’s NBFC KYC Directions gives a concrete downstream deadline. When an NBFC obtains additional or updated customer information under clause 10 or Rule 9(1C) of the PML Rules, it must furnish it to CKYCR within seven days, or another period notified by the government. This is a scoped KYC obligation, not a universal seven-day deadline for every profile edit.
Record when the information was obtained separately from when an internal approval became effective. Starting the timer only after the service desk marks a request complete could conceal delay. Assign verification and submission work early enough to meet the applicable deadline, and retain the submission and acknowledgement references.
The flow also runs in the other direction. CKYCR notifies reporting entities of an updated record; the NBFC must retrieve that record and update its own maintained information. Test both outbound updates and incoming notifications. A successful local save establishes neither.
Keep three states separate
Requested means the borrower has submitted a change. Approved and effective means the authorised record has changed at a defined time. Applied downstream means the relevant destinations have confirmed the approved version.
These states may occur together in a simple system. They will not always do so across partners and scheduled exports. A screen that reduces all three to “updated” hides the period when the institution is operating with conflicting information.
Store the request and decision references alongside the record version. Preserve enough controlled history to establish what changed, who authorised it and when it took effect. Avoid spreading copies of sensitive documents through general application logs. Evidence references with appropriate access can be more useful than uncontrolled duplication.
The LMS integration guide covers the surrounding connections. For customer changes, the additional design question is which connection must confirm application before a particular action can resume.
Rehearse a partial update
In this illustrative contact-change test, at 10:00, a borrower submits a contact change. At 11:20, the lender completes its verification and makes version 18 effective in the customer record. The communications service acknowledges version 18 at 11:21. A collections partner’s update fails, leaving its exported task on version 17.
At 11:30, should the case say “completed”? The answer depends on what that word promises. If it promises that all affected contact workflows use the new number, the evidence does not support it.
Keep the approved change in place. Assign the failed partner update to an owner and apply the lender’s rule for preventing use of the superseded contact. An agent can receive a controlled replacement task or the affected contact action can remain held pending correction. The exact remedy depends on the partner interface and approved process.
Now introduce a delayed acknowledgement for version 17. It must not overwrite version 18 or close the outstanding work. A retry also should not create a second customer or repeat a side effect. Require the destination’s response to identify which change it applied, rather than accepting any recent success message.
This case tests something different from whether an API is reachable: whether the organisation can retain a valid customer decision while repairing a failed dependency.
Treat bank details and payment authority separately
A borrower’s bank account can be stored correctly while a replacement repayment arrangement remains pending. The customer master, mandate record and queued payment instruction answer different questions.
Before switching the affected workflow, establish the authorised arrangement, its activation result and effective date. Review any instruction already queued against the previous arrangement. Do not infer that editing a bank field has cancelled an instruction or authorised a new debit.
Similarly, an address correction should not silently rewrite the historical address on a document already issued. Preserve the original record and use the appropriate controlled correction process where needed. Otherwise a later complaint may become harder to explain precisely because the current screen looks tidy.
The account-history investigation illustrates why an approved request, an executed change and the resulting borrower communication need separate evidence.
Tell the borrower what is actually complete
A useful status might say that the verified contact record has been updated while a specific service request remains under review. The wording must match the case and avoid exposing sensitive internal risk information. Do not promise that all channels have changed when only the LMS has confirmed success.
For the operations team, measure unresolved downstream updates by age and consequence. A count of successful profile edits can rise while the oldest failed contact update remains unattended. Check whether closed cases contain the required acknowledgements, whether superseded destinations were used after the effective time, and whether exceptions have owners.
An AI assistant can help summarise the case and draft the borrower response. It should work from the verified states and permitted evidence, with the lender’s controls governing consequential changes. Lokta’s Loan Management and AI Loan Servicing belong in that post-approval operating discussion. Evaluate the actual interfaces and controls against this case before assuming that a particular partner or registry is connected.
The completion rule should be visible before an operator clicks “done”: which record changed, which destinations confirmed it and which deadline remains open. Review that workflow with Lokta using one failed destination and one late acknowledgement.
Frequently asked questions
Does changing a borrower’s details in the LMS update every connected system?
That depends on the integrations and their completion rules. A local save does not establish that a communications provider, collection agency or external registry has applied the change. Track the destinations relevant to the field, the version they acknowledged and any unresolved failure. Distinguish receipt of a request from its application. The lender should be able to explain both the current approved record and the work still needed elsewhere.
Should contact, identity and repayment bank changes use one approval process?
They can share case tracking, but their evidence and consequences differ. A contact change can redirect communications, an identity change can affect customer due diligence, and a bank change can affect repayment arrangements. Define verification and approval for each under the lender’s policy and applicable requirements. Also assess combined requests: changing a contact channel should not automatically make that new channel sufficient evidence to authorise every subsequent request.
Does a new bank account in the customer record replace an existing repayment mandate?
No. A stored bank field and an authorised, active payment arrangement are separate facts. Check the mandate outcome, effective date and pending instructions before changing the repayment workflow. Tell the borrower which part is complete and which part remains pending.
When must an NBFC update CKYCR?
For additional or updated customer information covered by paragraph 63(7) of the NBFC KYC Directions, the NBFC must furnish it to CKYCR within seven days of obtaining it, or another government-notified period. Keep that timestamp separate from the internal approval date and track submission acknowledgement.
Read next
- LMS integration planning: map the systems that consume borrower information
- Reconstruct an EMI dispute: preserve the account history needed to explain a complaint
Sources
- RBI: NBFC Know Your Customer Directions, 2025: updated December 29, 2025; paragraph 63(7) supplies the update deadline and incoming-notification requirement; paragraphs 6 and 13 retain KYC responsibility. Checked 2 October 2026. The contact-change test is illustrative
Lokta editorial analysis by Chandramouli, co-founder and CEO.
