RCS OTP in India: Is It RBI Compliant? BFSI Guide 2026

The Compliance Question Every BFSI Team Asks First

Before any Indian bank, NBFC, or fintech approves a new communication channel for OTP delivery, one question dominates the discussion: "Is it RBI compliant?"

It is the right question to ask. Getting it wrong means regulatory exposure, potential audit findings, and real customer harm if authentication fails.

RCS (Rich Communication Services) is increasingly being evaluated by Indian BFSI teams as an OTP delivery channel — primarily because it adds verified business branding and anti-phishing properties that plain SMS lacks. But the evaluation almost always stalls on the compliance question, because:

• RCS is not governed by TRAI's DLT framework (which SMS uses)
• RCS natively supports clickable buttons and links — but RBI prohibits links in OTP messages
• The RBI circulars that govern 2FA are written for SMS, not for RCS

This guide answers every compliance question that Indian BFSI teams need resolved before deploying RCS OTP.

The Governing RBI Regulations

Two RBI circulars are most relevant:

RBI Circular DBR.No.Leg.BC.78/09.07.005/2017-18 mandates that all Scheduled Commercial Banks, Regional Rural Banks, Small Finance Banks, and Payment Banks send SMS alerts for all electronic banking transactions. This established SMS as the baseline authentication channel. RBI Master Direction on Digital Payment Security Controls (RBI/2024-25/105) reinforces 2-factor authentication requirements for digital payment transactions and explicitly states that OTP messages must not contain clickable links or URLs that could facilitate phishing.

The no-link rule is the most operationally significant constraint for RCS OTP deployment. Here is why it matters and how to comply.

The RCS + No-Link Rule: The Critical Configuration Point

RCS messages natively support three types of interactive elements:

• Suggested reply buttons (tap to send a quick response)


• Action buttons (tap to open URL, dial number, or share location)


• Suggested actions embedded in rich cards

For standard RCS marketing messages, these buttons are a feature. For RCS OTP messages, action buttons that contain URLs must be disabled.

An RCS OTP message that is RBI-compliant looks like this:

[BankName] Your OTP for transaction of ₹12,500 to HDFC A/c ending 4821 is 847293. Valid for 10 minutes. Do not share with anyone.

No buttons. No links. No "Verify Now" button. Just the OTP code and the transaction context.

This is not a limitation of RCS — it is a configuration choice. Authorized RCS aggregators can deploy OTP message templates with zero interactive elements, satisfying the RBI no-link requirement while retaining the one property that makes RCS OTP meaningfully superior to SMS OTP: verified business sender identity.

What RCS OTP Offers That SMS OTP Cannot

Even when configured without buttons or links (as required for RBI compliance), RCS OTP delivers three advantages over plain SMS OTP:

1. Verified Sender Identity — The Anti-Phishing Case

SMS OTP is vulnerable to sender ID spoofing. A fraudster can register a sender ID like "HDFC-BK" or "AXS-BNK" that visually mimics a legitimate bank's SMS sender ID. Users cannot verify the sender identity from within the SMS interface.

RCS OTP arrives with your bank's verified profile: logo, full name, and a carrier-verified badge shown at the top of the message thread. This visual verification is provided by Google's Jibe Cloud infrastructure and cannot be spoofed — a fraudulent sender cannot impersonate a verified RCS business sender profile.

For BFSI institutions, this is a meaningful anti-phishing property that strengthens customer protection beyond what SMS can offer.

2. Transit Encryption

SMS messages travel over the SS7 protocol in plaintext. SS7 vulnerabilities are well-documented and have been exploited to intercept OTPs in targeted attacks (primarily against high-value targets, but the vulnerability is structural).

RCS messages use TLS (Transport Layer Security) for transit encryption between the sender, the carrier network, and the recipient device. This provides a significantly stronger security profile for OTP delivery.

3. Read Receipts Enable Smarter Retry Logic

SMS OTP has no delivery confirmation beyond "delivered to network." You do not know if the customer actually saw the OTP. RCS OTP provides read receipts — your system knows when the OTP was opened. This enables more intelligent retry logic: send an SMS fallback only if the RCS OTP has not been read within 60 seconds, rather than triggering automatic retry after a fixed timer.

Does RCS Fall Under TRAI's DLT Framework?

This is the question that creates the most confusion. The short answer: RCS business messaging in India does not currently operate under TRAI's DLT framework.

DLT (Distributed Ledger Technology) compliance is a TRAI mandate specifically for SMS A2P (Application-to-Person) messaging. It requires:

• Pre-registration of sender headers with telecom operators


• Pre-registration of message templates


• Consent management records


• Scrubbing against the NDNC (Do Not Disturb) registry

RCS business messaging in India operates through a parallel but separate framework: Google's Jibe Cloud aggregator network. RCS senders are verified by Google (not by TRAI), message templates are approved by Google's review process (not pre-registered on DLT), and the consent framework is managed at the aggregator level.

What this means for compliance:

For BFSI teams, the absence of DLT registration does not mean RCS is unregulated — it means it is regulated differently. The relevant compliance framework is:

• RBI OTP rules (no links, transaction context required, valid period disclosure) — applicable regardless of channel
• DPDP Act 2023 (Digital Personal Data Protection Act) — data residency, consent logging, audit trail requirements — applicable to all digital communications
• Google's RCS Business Messaging policies — sender verification, anti-spam controls, opt-out requirements

The absence of DLT registration should not be confused with absence of compliance requirements.

The DPDP Act 2023 Dimension

The Digital Personal Data Protection Act 2023 became enforceable in phases through 2024–2025. For RCS OTP, the relevant requirements are:

Consent basis for transactional messages: OTP messages sent as part of a financial transaction can be sent on the basis of contractual necessity — the bank's account agreement with the customer typically covers transaction authentication communications. Explicit consent is not required for transactional OTPs under DPDP. Data minimization: RCS OTP messages should contain only what is necessary for authentication — OTP code, transaction reference, validity period. No supplementary personal data should be included. Audit trail: The RCS aggregator must maintain delivery logs that can be produced for regulatory audit. Scalify Labs' RCS platform maintains 90-day delivery logs per sent message as standard.

How to Implement RCS OTP for Your BFSI Institution

Step 1 — Engage an authorized RCS aggregator

Work with a Google-authorized RCS aggregator for India. They handle the brand verification process with Google (5–7 working days) and create your verified sender profile.

Step 2 — Create a compliant OTP template

Your OTP message template must:

• Include your verified brand name
• Include the OTP code clearly
• Include the transaction amount and account reference (partial, masked)
• Include the validity period
• Contain no clickable links or URL action buttons
• Include a "Do not share with anyone" warning

Submit the template for approval through your aggregator.

Step 3 — Configure SMS fallback

RCS OTP should always have SMS as a fallback. If the recipient's device does not support RCS (iOS, older Androids, Samsung Messages users), the same OTP is delivered as plain SMS automatically. You pay RCS rate for RCS delivery, SMS rate for fallback.

Step 4 — Implement read receipt logic (optional but recommended)

Configure your OTP system to monitor read receipts. If the RCS OTP is unread after 60 seconds, trigger the SMS fallback. This reduces failed authentications without double-charging for successful RCS deliveries.