India's RBI E‑mandate & Digital Payments Rules (2026): Practical Compliance Checklist for Fintechs, Psps & Platforms

On 21 April 2026, the Reserve Bank of India issued its consolidated Digital Payments – E‑Mandate Framework under the Payment and Settlement Systems Act, 2007, replacing a patchwork of circulars that had governed recurring digital payments since 2019. The new framework reshapes how every fintech, payment system provider (PSP) and merchant platform in India must handle enrollment, authentication and customer consent for recurring card, UPI, PPI and e‑NACH transactions. For in-house legal, compliance and product teams, the digital payments e-mandate India rulebook now demands a coordinated sprint across technology, contracts and audit infrastructure, and the window for implementation is tight. This article delivers the practical, step-by-step compliance checklist those teams need right now.

Executive Summary and Key Compliance Decisions

The RBI E‑Mandate Framework consolidates and supersedes earlier RBI circulars on e‑mandates issued between 2019 and 2024. It establishes a unified set of requirements for all entities involved in recurring digital payment flows, banks, payment aggregators, PSPs and merchants, with a particular emphasis on Additional Factor of Authentication (AFA), transparent consent capture and customer remediation rights. Simultaneously, the RBI’s authentication directions and digital-lending supplements from 2025–2026 introduce layered obligations that interact directly with the e‑mandate rules.

The primary compliance decision this article answers is: Does your organisation need to change its enrollment flows, authentication logic or commercial contracts for recurring payments, and if so, what must change, by when, and who bears the risk?

The immediate action list for fintechs, PSPs and platforms is as follows:

1. Days 1–30: Map every recurring payment product to the framework’s scope categories; identify which AFA threshold applies to each flow.
2. Days 1–30: Engage your bank partner or aggregator to confirm API-level support for the revised enrollment and AFA specifications.
3. Days 30–60: Update enrollment UX, consent capture screens and customer-facing terms to comply with e‑mandate registration requirements.
4. Days 30–60: Draft and circulate revised vendor SLAs and contract clauses allocating AFA, evidence-retention and remediation obligations.
5. Days 60–90: Enable audit logging for all mandate registrations, modifications, cancellations and AFA events; test evidence retrieval workflows.
6. Days 60–90: Conduct end-to-end testing of failed-payment handling, cancellation flows and customer complaint escalation paths.

Primary Compliance Decision, What Each Fintech and PSP Must Decide Now

Every entity processing recurring payments in India must answer a single threshold question: Do we need to change enrollment, authentication or contracts for our recurring flows? In almost every case, the answer is yes. The decision tree below provides a structured path to the key actions required.

• Step A, Scope mapping: Does your product collect recurring payments via cards, UPI, PPI or e‑NACH? If yes, the E‑Mandate Framework applies. List every recurring product line and classify it by payment channel.
• Step B, AFA threshold check: For each product, determine the per-transaction amount. If the amount exceeds the applicable AFA threshold for that channel, your flow must include Additional Factor of Authentication (typically OTP) at the point of each debit. If it falls below the threshold, AFA is required only at mandate registration, not at each subsequent debit.
• Step C, Vendor and contract review: Has your bank partner, aggregator or sub-processor confirmed technical readiness? If not, escalate immediately. Do your existing contracts allocate AFA responsibility, evidence-retention duties and indemnity for failed compliance? If not, renegotiate.
• Step D, Evidence and remediation readiness: Can you produce, within 48 hours of a regulator request, a complete audit trail showing consent capture, mandate registration, every AFA event and any modification or cancellation? If not, build the logging infrastructure now.

Industry observers expect that the organisations most at risk of enforcement action are those that treat the framework as a purely technical exercise. The practical reality is that legal, product and operations teams must work in concert, compliance is a three-legged stool, and any weak leg will invite regulatory scrutiny.

Overview, RBI E‑Mandate Framework: Legal Basis and Scope

Legal Basis and Definitions

The Digital Payments – E‑Mandate Framework, 2026, issued on 21 April 2026, derives its authority from the Payment and Settlement Systems Act, 2007 (PSS Act). The PSS Act empowers the Reserve Bank to regulate and supervise payment systems operating in India, including the power to issue directions to payment system operators, participants and providers. The 2026 framework was issued as a Master Direction under Section 18 of the PSS Act, read with Section 10(2).

An e‑mandate, as defined in the framework, is a digital authorisation given by a customer to a payment system provider or merchant, permitting recurring debits from the customer’s account (bank account, card, UPI-linked account or PPI) for a specified purpose, amount ceiling and frequency. Additional Factor of Authentication (AFA) refers to an authentication step beyond the payment instrument itself, typically a one-time password (OTP), required at mandate registration and, depending on thresholds, at individual debits.

The framework repeals and consolidates earlier RBI circulars on e‑mandates issued between 2019 and 2024, creating a single, unified reference point for all recurring digital payments in India.

Entities in Scope and Applicability

The framework applies broadly across the payments ecosystem. The following entities are directly covered:

• Banks and issuers, all scheduled commercial banks, co-operative banks and regional rural banks operating payment systems.
• Payment System Providers (PSPs), entities authorised under the PSS Act to operate payment systems, including UPI applications and card networks.
• Payment Aggregators (PAs), entities authorised by RBI to facilitate e‑commerce and merchant payments, including online payment gateways.
• Prepaid Payment Instrument (PPI) issuers, wallet providers and other PPI licensees.
• Merchants and platforms, while not directly regulated under the PSS Act, merchants using recurring payment flows are subject to obligations through their contractual relationships with banks and aggregators, and must ensure compliant consent capture and cancellation flows.

Authentication Rules and Thresholds (AFA), Practical Implementation

AFA Logic and Enrollment

Under the RBI E‑Mandate Framework, AFA is mandatory at the point of e‑mandate registration for all payment channels and all transaction amounts. This means every customer must complete OTP or equivalent authentication when first authorising a recurring payment, regardless of whether the recurring amount is ₹500 or ₹50,000.

The more nuanced question is when AFA is required for subsequent individual debits under an existing mandate. The framework establishes a tiered approach tied to the per-transaction amount and the payment channel:

For all channels, the payment system provider must send a pre-debit notification to the customer at least 24 hours before the scheduled debit date, disclosing the amount, date and merchant name. The customer must have the ability to opt out, modify or cancel the mandate at any time without charge.

Implementation Timelines and Migration Windows

The framework took effect on 21 April 2026. Industry observers note that the RBI has historically permitted a transition window for technical implementation following the issuance of such directions. Entities already compliant with the earlier e‑mandate circulars from 2019–2024 will find that most enrollment and authentication flows require refinement rather than wholesale replacement, but the new consolidated requirements for evidence retention and consumer remediation are net-new obligations for many organisations.

Product and compliance teams should treat the first 90 days following the framework’s effective date as the critical implementation sprint, aligning with the action list set out in the Executive Summary above.

Operational Exceptions, EMI and Loan Repayments

The framework’s AFA thresholds apply to the general category of recurring payments. The ₹1,00,000 elevated threshold for UPI e‑mandates applies only to three specified categories, subscription services, insurance premium payments and mutual fund SIP contributions, and does not extend to EMI or loan repayments. Early indications suggest that EMIs and loan repayments continue to be governed by the standard ₹15,000 threshold, meaning that any loan EMI above ₹15,000 will require per-debit AFA. Lenders and RBI digital lending 2026 compliance teams must factor this into product design, as the practical effect is that most home loan, auto loan and personal loan EMIs will trigger per-debit OTP requirements.

Flow-by-Flow Implementation Checklist for Recurring Payments Compliance

Cards (Credit and Debit)

Card-based recurring payments have been subject to e‑mandate rules since 2019, but the 2026 framework introduces additional requirements for consent record-keeping and cancellation flows.

• Enrollment UX: The mandate registration screen must clearly display the merchant name, maximum debit amount, frequency (monthly, quarterly, etc.), mandate validity period and the customer’s right to cancel at any time.
• Consent capture: Record the customer’s explicit consent with a timestamp, device identifier and the AFA completion event. Store a digitally signed consent artifact.
• Verification method: AFA (OTP via issuing bank) at mandate registration. No per-debit OTP for transactions at or below ₹15,000.
• Pre-debit notification: Send SMS/email/push notification at least 24 hours before each debit with amount, date and opt-out mechanism.
• Failed-payment handling: If a debit fails, do not retry without a fresh pre-debit notification. Log the failure reason and timestamp.
• Cancellation: Customers must be able to cancel via the issuing bank’s app, website or customer service channel. Cancellation must take effect before the next scheduled debit.

UPI E‑Mandate (NPCI)

UPI e‑mandate implementation involves interaction with NPCI’s UPI infrastructure and the customer’s UPI-linked PSP application.

• Enrollment UX: Mandate creation via the UPI collect flow; the customer approves the mandate on their UPI app with UPI PIN (AFA).
• Consent capture: NPCI’s system generates a Unique Mandate Number (UMN). Record the UMN, customer VPA, mandate amount ceiling, frequency, start and end dates.
• AFA thresholds: Per-debit AFA required above ₹15,000 (general) or above ₹1,00,000 for the three specified categories. Product teams must tag each mandate with the correct category code during creation.
• Pre-debit notification: Mandatory 24-hour advance notification. NPCI’s infrastructure supports automated notification triggers, but the merchant/PSP must confirm delivery.
• Modification and cancellation: Customers can modify or revoke mandates directly through their UPI app. The PSP must support inbound revocation callbacks and halt subsequent debits immediately.

PPI (Wallets and Prepaid Instruments)

PPI-based recurring payments are a newer use case and require careful attention to the digital payments e-mandate India rules.

• Enrollment UX: PPI issuer must authenticate the customer at mandate registration using the PPI’s in-app authentication mechanism (PIN, biometric or OTP).
• Consent capture: Record consent artifact within the PPI issuer’s system, including wallet ID, merchant identifier, amount ceiling and frequency.
• AFA threshold: ₹15,000 per transaction for subsequent debits; per-debit AFA required for amounts above this threshold.
• Pre-debit notification: Same 24-hour rule. PPI issuers must deliver notification via in-app push or SMS.
• Balance checks: PPI issuers must verify sufficient balance before executing the debit; failed debits due to insufficient balance must be logged and the customer notified.

e‑NACH and Bank Debit Flows

e‑NACH (Electronic National Automated Clearing House) mandates represent the traditional bank-debit route and remain widely used for insurance premiums, SIPs and utility payments.

• Enrollment: Digital mandate registration via the sponsor bank, authenticated with Aadhaar e‑Sign, debit card OTP or net banking credentials.
• Consent capture: Sponsor bank retains the signed mandate image or digital artifact. The UMRN (Unique Mandate Reference Number) must be stored by all parties in the chain.
• AFA threshold: Standard ₹15,000 rule applies. Pre-debit notification mandatory at least 24 hours before debit.
• Settlement and reconciliation: Destination banks must process mandated debits within the NACH settlement cycle. Failed debits trigger return codes; the sponsor bank and merchant must log return reasons.
• Cancellation: Customers can cancel via the destination bank. Banks must provide an online cancellation facility and process cancellations before the next debit cycle.

Contracts, Vendor Management and Allocation of Liability

The E‑Mandate Framework places obligations across the payments chain, but the allocation of responsibility between banks, aggregators, PSPs and merchants is ultimately governed by contract. Payment aggregator obligations in India now require explicit contractual terms addressing AFA, evidence retention and remediation. The table below summarises obligations by entity type:

Sample Contract Clauses

The following four clause templates address the most critical contractual gaps created by the framework. These should be adapted to each organisation’s specific risk profile and commercial context.

• Clause 1, Authentication and AFA Responsibilities: “The Payment Service Provider shall ensure that Additional Factor of Authentication is executed in accordance with the RBI’s Digital Payments – E‑Mandate Framework for all mandate registrations and for all subsequent debits exceeding the applicable AFA threshold. The PSP shall be solely responsible for routing AFA requests to the issuing bank and shall indemnify the Merchant against any regulatory penalty arising from the PSP’s failure to execute AFA as required.”
• Clause 2, Evidence and Log Retention: “Each party shall retain complete records of all mandate registrations, AFA events, pre-debit notifications, mandate modifications and cancellations for a minimum period of ten years from the date of the last transaction under the mandate, or such longer period as may be required by applicable law. Records shall be maintained in a format that permits retrieval and production to the regulator within 48 hours of a request.”
• Clause 3, Incident Response and Remediation: “In the event of any unauthorised debit, failed AFA, or customer complaint relating to a recurring payment processed under this Agreement, the responsible party shall initiate remediation within 24 hours and shall complete reversal or resolution within the timelines prescribed by the RBI’s customer grievance redressal framework. Each party shall notify the other of any such incident within 12 hours of becoming aware of it.”
• Clause 4, Audit and Compliance Cooperation: “Each party grants the other party, and any regulator with jurisdiction, the right to audit compliance with the E‑Mandate Framework upon reasonable notice. The audited party shall provide full access to relevant systems, logs and personnel. The parties shall cooperate in good faith with any RBI inspection or inquiry relating to recurring payment flows processed under this Agreement.”

Audit, Evidence and Remediation Playbook

What to Retain: Fields and Format

Compliance with the RBI E‑Mandate Framework requires robust evidence infrastructure. At a minimum, organisations must retain the following data elements for every recurring payment mandate:

• Customer identifier (masked account number, VPA or card token)
• Mandate registration timestamp, device fingerprint and IP address
• AFA completion event (OTP delivery timestamp, OTP verification timestamp, authentication result)
• Consent artifact (screen capture or digitally signed consent record)
• Pre-debit notification delivery confirmation (timestamp, channel, delivery status)
• Each debit execution record (amount, date, result, AFA event if applicable)
• Modification and cancellation records (timestamp, initiator, reason)

Evidence Retention Schedule

Preparing for RBI Inspection and Consumer Remediation

Organisations should designate a single internal owner (typically the Chief Compliance Officer or Head of Payments Compliance) responsible for producing evidence within 48 hours of a regulatory request. Consumer remediation under the framework requires that any unauthorised or disputed recurring debit be reversed within the timelines prescribed by the RBI’s Integrated Ombudsman Scheme. Product teams must build automated reversal workflows that can be triggered without manual intervention when a complaint meets defined criteria.

Regulatory and Supervisory Liaison, Notifications and Reporting

The fintech compliance checklist for India must include a clear internal owner matrix for regulatory interactions. The framework requires entities to report material incidents, including systemic AFA failures, data breaches affecting mandate records, or large-scale customer complaints, to the RBI’s Department of Payment and Settlement Systems.

Implementation Timeline, Project Checklist and 90‑Day Sprint Plan

The following payment system provider checklist organises the critical workstreams by team and timeline:

• Days 1–30 (Legal + Product): Complete scope mapping; identify all in-scope recurring products; classify by channel and AFA threshold; gap-assess current enrollment UX against framework requirements; begin contract redline for top-priority vendor agreements.
• Days 1–30 (Engineering + Security): Confirm bank/aggregator API readiness for revised AFA flows; begin development of pre-debit notification delivery and logging infrastructure; enable audit trail capture for mandate lifecycle events.
• Days 30–60 (Legal + Compliance): Circulate revised vendor SLAs and contract amendments; finalise evidence-retention policy document; update internal compliance manual and training materials.
• Days 30–60 (Product + Engineering): Deploy updated enrollment UX to staging; implement cancellation and modification flows; build automated reversal workflows for disputed debits; begin integration testing with bank partners.
• Days 60–90 (All Teams): Conduct end-to-end testing across all channels (cards, UPI, PPI, e‑NACH); execute tabletop exercise for RBI inspection scenario; sign off on updated vendor contracts; go live with production logging and monitoring dashboards; complete staff training.

Conclusion

The RBI’s 2026 E‑Mandate Framework is not merely a technical update, it is a structural reset of how recurring digital payments must be authorised, evidenced and governed across India’s payments ecosystem. For fintechs, PSPs and platforms, the compliance imperative spans product engineering, commercial contracts and audit infrastructure in equal measure. Organisations that treat digital payments e-mandate India compliance as a coordinated, cross-functional programme, rather than a siloed engineering task, will be best positioned to avoid enforcement risk and to build the trust-based recurring revenue models that India’s digital economy demands.

Sources

1. Reserve Bank of India, Digital Payments E‑Mandate Framework (Master Directions)
2. National Payments Corporation of India (NPCI), UPI Product Overview
3. Payment and Settlement Systems Act, 2007, India Code
4. Reserve Bank of India, Notifications and Master Directions Index
5. Ministry of Electronics and Information Technology (MeitY)