Which rules does an EMI reminder call meet?
Four sets, and your compliance team owns the reading of each. What follows is what we build so the rules hold on every call. It is a summary for planning, not legal advice, and we can't name clients, so it shows the controls and the tests rather than a case study.
The RBI text for NBFCs lists, among harsh recovery practices, "making threatening and/ or anonymous calls, persistently calling the borrower and/ or calling the borrower before 8:00 a.m. and after 7:00 p.m. for recovery of overdue loans." The Digital Lending Directions of 8 May 2025 say the recovery agent's particulars "shall be communicated to the borrower through email/ SMS before the recovery agent contacts the borrower."
For the number series, TRAI's direction of 19 November 2025 set 1 February 2026 for NBFCs with assets above ₹5,000 crore and 1 March 2026 for the remaining NBFCs. After those dates, it says, such entities "shall not be permitted to initiate any service or transactional voice calls" from numbers outside the 1600 series, "even with the explicit or inferred consent of customers."
Recording is a choice we make. The Economic Times reported RBI's draft conduct rules asking banks to record recovery calls and tell the borrower. That draft is written for banks; we record every NBFC reminder the same way, because the recording is your evidence when a borrower complains.
Does the 8-to-7 window apply to a pre-due reminder?
RBI's wording covers calls "for recovery of overdue loans", so a reminder three days before the due date may fall outside it. We apply the window to every call anyway, by choice.
The borrower cannot tell a pre-due reminder from a recovery call. A call at 7:40 p.m. reads as harassment whatever your call type says, and a complaint does not arrive with your internal label attached. One rule is also easier to audit than two. If your compliance team reads it differently, the window is a setting, and the spec records who decided.
Where do the checks sit?
Outside the model, in one place every call passes through. The agent never decides whether a call happens.
If your dialler can read the loan record at dial time, the pre-dial check lives in it. If it cannot, a small service sits between the campaign and the dialler and answers yes or no. Either way the model has no credential that lets it dial, and the check would still refuse a call the model asked for at 7:40 p.m.
Two more requirements go in the spec:
- One identity per agent. Each agent gets its own Salesforce integration user and permission set. Switching one off stops that agent and nothing else, and the audit trail names which agent wrote which field, not "the bot".
- Fail closed. If the check cannot read the loan record, the stop flags or the clock within its timeout, the answer is no, logged as a failed lookup. A Salesforce outage stops the campaign; it never lets calls through unchecked. We test it before go-live by cutting the check's connection in a test org and confirming the dialler places no calls.
The model calls go through one gateway every time. It allows only the models named in the spec, caps tokens per call, and masks loan numbers and dates of birth in what it logs. With Sarvam, the agent speaks Hindi, Bengali, Tamil, Telugu, Gujarati, Kannada, Malayalam, Marathi, Punjabi, Odia and English, and understands 22 Indian languages. Sarvam's managed service is India-hosted by default, on Azure's Central India region according to its trust center, which lists SOC 2 Type II, ISO 27001 and a DPDP data processing agreement. Its retention docs say a workspace keeps data until an owner sets a period, and zero retention is not yet available for Voice Agents. Set the period before the first call, to match your own recording policy.
What does the build enforce?
These checks run in code before and during each call:
- 01Calling window. The pre-dial check refuses any call outside 8 a.m. to 7 p.m. in the borrower's time, and any time the borrower asked you to avoid, read from the record.
- 02Attempt cap. A daily and weekly cap per borrower, set by your policy and stored on the loan record, so repeated dialling cannot become persistent calling.
- 03Caller ID. Reminders go out only from your registered 1600-series numbers. A reminder campaign set to a 140 number is refused.
- 04Loan active. TRAI treats implicit consent for service calls as valid only while the contract runs, so a closed loan gets no reminder.
- 05SMS first, where required. When a recovery agent or service provider is assigned or changes on a digital loan, the details go by SMS before the first call, and the check stores the SMS message ID with the call.
- 06Opening lines. The agent names the lender, says it is an automated call and that the call is recorded, and asks for the borrower by name.
- 07Verification. Before any loan detail, the borrower confirms two items held on the record, such as date of birth and the last four digits of the loan account. The agent never reads them out first. A failed check ends the loan conversation, offers a call-back on the registered number and is logged.
- 08Borrower only. If someone else answers, the agent says nothing about the loan and offers a call-back.
- 09No offers. The script carries no product pitch. A borrower who asks about a top-up is handed to a person on the right channel.
- 10Hand-off. Disputes, hardship, a death in the family, anger or any request to stop calling go straight to a person's queue, with the transcript.
Language belongs on this list too. A reminder in a language the borrower does not speak well produces a "yes" that means nothing. Call in the language stored on the record. Our India page lists the languages and the rules we build for.
What does one call leave on the record?
Two things: the outcome your collections team reads, and a trace your auditor reads.
The trace is append-only. The check and the write-back tool can add rows, and nobody can edit or delete one, your admins and ours included. Keep it outside the agent's reach in write-once storage with a retention lock, which most clouds offer, for the period your compliance team sets in the spec, so an auditor can rely on it.
If you run Salesforce Financial Services Cloud, the fields sit on the loan or financial account. On other Salesforce clouds, a custom object linked to the account works the same way. The integration user gets edit access to these fields and nothing else on the record. Turn on field history for them, so every change shows who made it and when.
How do you stop it?
At three levels, each a setting, not a release.
- One borrower. A stop flag on the loan, set by a person or by the agent when the borrower asks. The pre-dial check reads it before every dial.
- One campaign. A pause on the campaign. The next dial is refused, and calls in progress finish or transfer.
- The whole agent. Switch off its integration user and its dialler queue. No call starts and nothing writes.
Who may use each one is in the spec. Any collections user can set a borrower stop flag. The collections head and the compliance head can pause a campaign or the whole agent. Only the named owner restarts one. Every flip goes into the trace with who, when and why.
The stop time is a requirement, and we have no measured figure to quote you. We write it into the spec as: no dial starts after a pause is saved, and calls in progress end or transfer within 60 seconds. That is our default target; set your own. To test it, start a campaign against test numbers, save the pause, and compare its time with the dialler's log. Any dial after the pause fails the test.
Undo is the fourth control. Every agent write carries the call ID, so one report lists everything a bad batch changed, and field history shows the value before it. We test all three stops and one undo before go-live.
The speed matters because the penalty is on your numbers. TRAI's February 2025 amendments set action against a sender at 5 complaints in 10 days. For a first breach, outgoing services on all the sender's telecom resources are barred for 15 days; for later breaches, all its telecom resources are disconnected across operators for a year and the sender is blacklisted. One bad campaign can take your service line down, so the pause has to stop the next dial.
What changes when the loan is overdue?
More of the rules bind, and more calls go to a person. On a pre-due reminder the 8-to-7 window is our choice; on a call to recover an overdue loan it is RBI's rule. So is the SMS: on a digital loan, the recovery agent's details reach the borrower before the first recovery call. For loans 1 to 30 days past due, we keep the same agent and the same checks, with three changes:
- The outcome codes add the bounce reason and a broken-promise flag. A second missed date goes to a person, not another automated call.
- A borrower who has broken a promise, disputes the amount or mentions hardship is called by a person from then on.
- A field-visit request becomes a task for your field team. The agent never promises a visit.
Later buckets stay with your people. Three practical points come up in every collections review:
- The language on the record is wrong. If the borrower answers in another language the spec covers, the agent switches; if not, it hands off. Either way it flags the record for a person to correct.
- The exception queue is yours. Hand-offs land with your telecallers or agency, so size the queue from the hand-off rate per language that the shadow run gives you.
- 1600 numbers come from your telecom operator. TRAI directed operators to start allotting them to eligible BFSI firms on 31 December 2024. Cost and lead time are not published, so ask your operator, and check your dialler can present a 1600 number before you fix a start date.
For cost per resolved call against a telecaller, with every assumption shown, see our Sarvam pricing post.
Where do reminder builds go wrong?
On the rules nobody wrote into code. The four we check first:
- The cross-sell line. TRAI keeps 1600 numbers for service and transactional calls and 140 numbers for promotion. We treat a reminder that ends with a top-up offer as a sales call on a service number. Keep the script clean and route interest to a person.
- Stale data. A borrower who paid this morning and gets a reminder this afternoon complains with good reason. Read the payment status at dial time, not from last night's list, and from your loan management system if that is where payments land first.
- A misheard amount. A promise of ₹4,000 heard as ₹40,000 is a wrong record and a wrong next call. During the gate a person approves every promise-to-pay write; after it, any amount that differs from the instalment by more than your set margin goes to a person.
- No record of consent and notice. The DPDP Rules were notified on 14 November 2025, and the notice and consent provisions apply from 13 May 2027. A recording with no notice record attached is hard to defend after that date. Store the notice, the language and the consent status with the call now.
How does this map to the frameworks you report against?
Directly, if your AI policy follows the NIST AI Risk Management Framework. Its four functions line up with the controls above:
For India, the DPDP duties sit on the same records: the notice, the consent status and the retention date travel with each call.
Is anyone running reminders like this at scale? Sarvam reports that voice agents built by Mahindra AI on its platform have made over one crore calls in 12 Indian languages. On collections, it says they cover "pre-due reminders through to write-off and repossession-stage conversations", with every call recorded and the results fed to CRM and collections systems. Sarvam reports call volume, not recovery or conversion figures.
What would we do in week one?
Read the process, then write the controls down. Week one ends with a written assessment you keep:
- 01Map how reminders run today: the dialler, the numbers, the list and when it is pulled, and who signs a script.
- 02Write the one-page spec for one loan product, one language pair and pre-due reminders: rules, fields, hand-off cases, and the window decision with its owner.
- 03Agree the trace, the three stops and the undo report with your compliance and security leads, and test that a 140 number and a 7:40 p.m. dial are both refused.
- 04Pick the recorded calls for the shadow run, and settle the hosting route and retention period in writing.
From there our target is one loan product in one language pair live in about 30 days, shadow period included, in our method: spec, shadow, gate. The agent writes nothing during the shadow run. In the gate, a person approves each promise-to-pay write. Add the next bucket or language only with the same spec and a fresh shadow run.
The use-case list has the other lending jobs this stack fits, and our Sarvam page covers the models, prices and limits. If you want a second pair of hands, send us the loan product, the languages your borrowers speak and how reminders run today, using the brief below. We put one agent on it with a person on the exceptions, as in First Agent in Production. You hear back within 24 hours from the person who signs the work.
