RBI outsourcing, DPDP, SEBI: call recording compliance for Mumbai BFSI operations

# RBI outsourcing, DPDP, SEBI — call recording compliance for a Mumbai BFSI operation

If you run a recovery, collections, or cross-sell desk out of BKC, Andheri, or Powai, your call recording stack is not just a QA tool. It is a regulated data pipeline that three separate regulators can audit — RBI under the Master Direction on Outsourcing of Financial Services, MeitY under the Digital Personal Data Protection Act 2023, and (if you sit inside a broker-dealer) SEBI under the 2013 stockbroker recording circular.

Most compliance officers I speak with in Mumbai have read all three. The gap is almost never in understanding the law. It is in reconciling the three different retention clocks, consent formats, and audit-trail expectations into a single architecture. This post walks through what each regulation requires in practice and how to build the recording layer once rather than three times.

What the RBI Master Direction actually says

The relevant documents are the RBI Master Direction on Outsourcing of IT Services (April 2023), the Guidelines on Managing Risks in Outsourcing of Financial Services by NBFCs (November 2017), and the 2006 outsourcing framework for banks. Three clauses do most of the work.

First, the regulated entity — bank, NBFC, or HFC — remains fully responsible for the acts of the service provider. If your recovery vendor in Vikhroli threatens a borrower or misrepresents a settlement offer, the RBI holds you accountable. Recording every conversation is your only evidence that agents followed the Fair Practices Code.

Second, the RBI expects you to have "the right to conduct audits" of the service provider — physical inspection, and access to books, records, and information relevant to the outsourced activity. Call recordings are explicitly in scope. Your vendor contract needs a clause giving you (and the RBI, on inspection) read access to raw audio, agent identities, timestamps, and telephony metadata within a defined SLA.

Third, on retention, the RBI does not name a fixed period in the outsourcing direction itself, but the Recovery Agents circular and the Fair Practices Code point recovery calls at a minimum of two years, and internal auditors push for five to align with the seven-year statute of limitations under the Limitation Act. Most BFSI ops in Mumbai settle on three years (recovery) or five years (cross-sell and advisory), reviewed annually.

If your vendor cannot demonstrate an immutable audit trail — who accessed which recording, when, and why — you fail the RBI inspection even if the audio is intact.

DPDP Act 2023: the new layer

The DPDP Act 2023 changed the consent question. Section 6 requires that consent be "free, specific, informed, unconditional and unambiguous with a clear affirmative action." For an outbound call:

• The pre-recorded consent line at call start must name the entity, the purpose (recovery / cross-sell / KYC), and the retention period.
• A generic "this call may be recorded for quality purposes" no longer clears the bar for financial conversations.
• Consent must be captured *before* any personal data — including account status or outstanding amount — is discussed.

Section 8 introduces Data Fiduciary obligations: you must be able to erase personal data when the purpose is served, unless a specific law requires retention. Here you get a genuine conflict with RBI. If a borrower invokes DPDP erasure but the RBI expects three years of retention, you retain — but you must document the legal basis and prove the recording is quarantined from active processing.

Section 7 covers "legitimate uses" — narrow exceptions where processing without fresh consent is allowed. Debt recovery is *not* automatically covered; the contract-performance basis under §7(a) is the usual anchor, and thinner than most vendors assume. If your transcripts train a scoring model, that is a distinct purpose and needs distinct consent.

SEBI's overlay for broker-dealer cross-sell

If your Mumbai operation includes a stockbroker entity, SEBI's circular CIR/MIRSD/24/2011 and the 2013 clarification apply to any call where investment advice is given or trades placed. Voice records must be retained for the applicable dispute resolution period — generally five years for exchange-traded products and eight for advisory.

The SEBI standard is stricter than RBI on two dimensions: recordings must be tamper-evident with cryptographic hashes or WORM (write-once-read-many) storage, and the mapping between the recorded voice, the client's Unique Client Code, and the resulting trade blotter must be reconstructible on demand. This is where many Mumbai broker-dealers get caught — the recording exists, but they cannot prove it corresponds to the specific order that was punched, because the dialer and OMS clocks drift by several seconds.

Retention math: one clock, three regulators

Run a single retention policy set at the longest applicable period, with per-campaign overrides where a shorter period is legally sufficient.

| Call type | Regulator | Minimum | Practical setting | |-----------|-----------|---------|-------------------| | Recovery / collections | RBI FPC | 2 years | 3 years | | Cross-sell of insurance | IRDAI + DPDP | 3 years post-policy | 5 years | | Investment advisory | SEBI | 5-8 years | 8 years | | KYC verification | RBI KYC MD | 5 years post-relationship | 8 years | | General customer service | DPDP only | Purpose-limited | 1 year |

The two axes to configure independently are retention period and access-control tier. Advisory recordings should be encrypted with a customer-managed key held by compliance. Recovery recordings can sit under an ops-managed key with quarterly compliance review.

Audit trail: what an inspection actually wants

The audit trail is where most vendor pitches fall apart. An inspector will ask for four artefacts:

1. Chain-of-custody log: for a given recording, every read, download, transcription, or share event, with user identity and reason code.
2. Retention journal: proof that recordings scheduled for deletion were deleted, and recordings under legal hold were not.
3. Consent-capture evidence: the specific audio segment where the customer consented, extractable as a standalone clip.
4. Time synchronisation proof: NTP logs showing the dialer, recording server, and CRM are within tolerance of IST reference time.

Storing audio in an S3 bucket with public-read blocked is necessary but nowhere near sufficient. You need lifecycle policies (S3 Object Lock in Compliance mode for SEBI scope), CloudTrail-equivalent access logging, and a schema tying each audio file to a specific agent login, campaign, disposition, and CRM record.

Consent capture: the bit most vendors skip

The DPDP requirement of "specific, informed, unambiguous" consent maps to a concrete telephony pattern. On dial connect, before the agent begins, an announcement plays: entity name, purpose, retention period, and a request for verbal consent. The customer's response is captured as a separate audio fragment, timestamped, and stored alongside the main recording with its own file reference.

If the customer declines, the call ends. If they consent, the agent proceeds and the consent fragment is linked to the parent recording. If they withdraw consent mid-call, that event is captured and downstream recording gets a different classification tag.

This is where dialer configuration matters. A predictive dialer that connects the customer to an agent before the consent prompt has played is technically recording without consent. TRAI's 3% predictive-abandon cap is unrelated — but the same architecture that solves for TRAI also has to solve for DPDP.

In dialque, the consent prompt is a first-step IVR node that runs on the dialer side before media is bridged to the agent, and the consent fragment is written as a separate S3 object with its own retention lifecycle. Recovery campaigns typically use progressive dialing rather than predictive, which sacrifices some agent utilisation for a cleaner consent chain. Ozonetel, Exotel, and Servetel can do this too, but you have to configure it explicitly; the default IVR templates rarely include a DPDP-compliant consent capture.

Three tools or one platform: honest tradeoffs

Most Mumbai BFSI compliance officers inherited a stack that looks like this: an outbound dialer (often Ozonetel or Ameyo), a recording archive (sometimes Verint or NICE, sometimes S3 direct), and a transcription/QA layer bolted on (often a third vendor wrapping Whisper or Sarvam).

The three-tool architecture works, but has three failure modes: (a) clock drift between the dialer's CDR timestamps and the archive's file timestamps, which breaks SEBI reconstruction; (b) inconsistent retention across three systems, which fails RBI audit; and (c) no single place to prove chain-of-custody, because access logs live in three systems.

A consolidated platform solves coordination but introduces vendor concentration risk. The BYOC (bring your own carrier) pattern — dialer software from one vendor but SIP trunk from Tata, Airtel, or Vi Business under your direct contract — de-risks that somewhat, because you can point a backup dialer at the same carrier during an incident.

For a Mumbai BFSI operation of 50-500 seats, the pragmatic architecture is: one dialer/recording/transcription platform (single audit trail, single retention config), self-hosted or VPC-deployed on AWS Mumbai (ap-south-1) for DPDP data-residency alignment, with a BYOC carrier arrangement so the telco layer is independently contractable.

Where dialque fits — and where it doesn't

dialque is one of the platforms that can be deployed this way. Recordings write to S3 with monthly folders and presigned URLs for controlled access, retention is configurable per campaign, and transcription plus AI summary stages run inline so the same audit trail covers audio, transcript, and disposition. Self-hosting on Asterisk inside your AWS Mumbai VPC keeps all personal data inside the region, which matters for the DPDP significant-data-fiduciary designation most BFSI entities will fall under.

Pricing is ₹1,500-₹2,500 per agent per month depending on tier, plus your own carrier and AWS costs. It is not the cheapest option in Mumbai — Servetel and MyOperator start lower — and it is not the most enterprise-heavy — Ameyo and NICE have deeper QA workflows. It sits in the middle: enough compliance plumbing for a serious BFSI audit, without the six-month integration timeline of the incumbents.

Where dialque is not the right answer: if you already have a working NICE or Verint archive that compliance trusts, ripping it out to consolidate is rarely worth it. Point the new dialer at the existing archive over SIPREC or a scheduled S3 sync, and consolidate only when the incumbent contract renews.

Implementation checklist

If you are scoping this for a Mumbai BFSI operation, the questions to put to any dialer vendor:

1. Where does the audio physically sit? AWS Mumbai, GCP Mumbai, or a Tier-III Indian datacenter — not Singapore, not Frankfurt.
2. What is the retention configuration granularity? Per-campaign is table stakes; per-disposition is better; per-consent-tier is best.
3. Show me the consent-capture audio fragment as a separate file with its own lifecycle policy.
4. Give me a CSV export of every access event on a specific recording for a specific month.
5. Prove clock sync between the dialer, recording server, and CDR — NTP source and drift tolerance.
6. What happens on a legal-hold flag? The recording must survive the retention deletion job.
7. Can I hold the encryption key myself (BYOK), or is it vendor-managed?
8. Under BYOC, which carriers are pre-integrated for Mumbai — Tata, Airtel, Vi Business, Reliance? What is the failover behaviour?

If a vendor cannot answer these on the first call, they are not ready for a BFSI compliance review, regardless of how polished the demo looks.