RBI's 2026 e-mandate rules: 11 things your billing system must do

Summary. On 21 April 2026 the Reserve Bank of India issued the Digital Payments – E-mandate Framework, 2026 under reference RBI/DPSS/2026-27/396, repealing eight circulars issued between 21 August 2019 and 22 August 2024 and replacing them with one set of Directions that took effect immediately. The headline numbers are unchanged: recurring transactions clear without additional factor of authentication up to ₹15,000 per transaction, and up to ₹1,00,000 for insurance premiums, mutual fund subscriptions and credit card bills. The pre-transaction notification still has to land at least 24 hours before the debit. What changed sits in two footnotes, and what most teams get wrong sits in clause 5(b). This is the engineering read: 11 build items, the exact notification payloads, and the three clauses that break a naive scheduler.

If you run subscriptions, SIPs, insurance renewals, UPI Autopay or any card-on-file recurring charge in India, the Directions are now the single document to build against. Everything before it is repealed.

What the framework is, in one paragraph

The Directions are issued "in exercise of the powers conferred by Sections 10(2) read with Section 18 of the Payment and Settlement Systems (PSS) Act, 2007", and they apply "to all Payment System Providers and Payment System Participants in respect of processing of recurring transactions, domestic or cross-border, using cards / PPI / UPI". Cross-border is in scope. PPIs are in scope. UPI Autopay is in scope. There is no transition window: clause 1(b) says the Directions "shall be effective immediately".

Definitions are not restated. The framework borrows authentication, factor of authentication, issuer and merchant from the Reserve Bank of India (Authentication mechanisms for digital payment transactions) Directions, 2025 dated 25 September 2025, and from the Master Direction on Regulation of Payment Aggregators dated 15 September 2025. If your compliance matrix does not already reference those two, it is incomplete, because the AFA definition your e-mandate code depends on lives in the 2025 authentication Directions, not here.

What is actually new, and it is only two things

Most coverage described the framework as a consolidation, which is accurate and slightly unhelpful. Read the primary text on rbi.org.in and there are exactly two footnotes, both marked as additions made after stakeholder feedback.

The first sits on clause 7. The post-transaction notification must now carry "details on grievance redressal", and the footnote records that "the requirement for providing details of grievance redressal is added, based on feedback." Your post-debit SMS and email templates need a new field. That is a template change, a character-budget problem on SMS, and a localisation problem if you serve non-English users.

The second sits on clause 10(b): "In case of cards, existing e-mandate(s) can be mapped to reissued cards", with the footnote "this clause is added based on feedback." This is the more consequential one. Card reissue — expiry, damage, network migration — previously meant a dead mandate and a re-registration flow with fresh AFA, which is where subscription businesses lose customers. The framework now permits mapping the existing mandate onto the reissued card. It says "can be", not "shall be", so this is an issuer capability rather than an issuer obligation, and whether your acquirer's stack supports it is a question to put to them in writing.

Everything else in the 2026 text was already binding under one of the eight repealed circulars. The value of the consolidation is that you can now point an auditor at one document.

The 11 build items

Item 9 is the one that reshapes the scheduler, and item 6 is the one teams most often miss: the AFA step-up on an update to an existing mandate, not just on creation.

The three clauses that break a naive implementation

Clause 5(b) disables the customer's own controls. The text reads: "Payments under e-mandates shall not be subject to any other limits / controls set by the customer." If your product exposes card controls — a per-transaction ceiling, a merchant-category block, an international toggle — those controls do not apply to e-mandate debits. That is deliberate, because a customer-set control silently killing an insurance renewal is worse than the debit going through. It is also a real behavioural surprise, and it means your control-evaluation path needs an explicit bypass for mandate-originated transactions rather than picking one up by accident.

Clause 6(a) is a 24-hour floor, not a target. "An issuer shall send a pre-transaction notification to the customer, at least 24 hours prior to the actual charge / debit." A scheduler that fires the notification and the debit from the same daily batch fails this. So does one that computes T minus 24 hours in local time across a DST-free but timezone-mixed deployment and lands 23 hours 55 minutes out. Build the notification as a separate job with its own idempotency key, schedule it at T minus 26 to 48 hours to leave margin, and record the send timestamp as evidence. If the notification fails to send, the debit must not proceed.

Clause 6(c) puts a cancellation window inside your billing cycle. The customer can opt out of "any particular transaction or the e-mandate", the opt-out must be AFA validated, and an intimation must follow. So between the notification and the debit there is a live 24-hour window in which a single scheduled charge can be cancelled without the mandate itself dying. Most billing systems model a charge as pending or captured. This needs a third state — notified, cancellable — and the debit job has to re-check it immediately before authorisation rather than trusting what the batch decided a day earlier.

Authentication thresholds

The limits are per transaction, not per month and not per mandate. A ₹40,000 monthly enterprise SaaS subscription needs AFA on every cycle; splitting it into three ₹13,333 debits to duck the threshold is the kind of structuring that will not survive an acquirer audit, and clause 10(c) makes your acquirer responsible for catching it.

Note also that the ₹1,00,000 band is defined by payment purpose, not by merchant category code alone. Classifying a debit as an insurance premium is a data-quality obligation, and getting it wrong in the permissive direction is the expensive error.

Notification payloads, field by field

The Directions specify minimum contents rather than a format, so these are the fields you must be able to populate.

One exemption: clause 6(d) removes the pre-transaction notification requirement "for e-mandates registered to auto-replenish balances of FASTag, and National Common Mobility Card (NCMC)". Auto-replenishment at a toll plaza cannot wait 24 hours. The post-transaction notification still applies.

A scheduler that satisfies clause 6

The shape that works is three separate jobs with a shared idempotency key, not one batch that does everything.

            # T-26h: notify. T-0: debit, but only if still cancellable=false.
# Idempotency key = (mandate_id, cycle_date) everywhere.

def schedule_cycle(mandate, cycle_date):
    key = f"{mandate.id}:{cycle_date:%Y%m%d}"
    enqueue("notify", key, run_at=cycle_date - timedelta(hours=26))
    enqueue("debit",  key, run_at=cycle_date)

def notify(mandate, cycle, key):
    if cycle.state != "scheduled":
        return
    send_pre_txn(mandate, fields=[
        "merchant_name", "amount", "debit_at",
        "mandate_ref", "debit_reason",
    ], channel=mandate.notify_channel)   # clause 4(d)
    cycle.notified_at = now()            # evidence for clause 6(a)
    cycle.state = "notified"             # cancellable window opens

def debit(mandate, cycle, key):
    # Re-read, do not trust the batch's day-old view (clause 6c).
    cycle.refresh()
    if cycle.state != "notified":
        return abort(cycle, "not notified or opted out")
    if now() - cycle.notified_at < timedelta(hours=24):
        return abort(cycle, "24h floor not met")
    if amount_needs_afa(mandate, cycle.amount):   # clause 8
        return request_afa(mandate, cycle)
    authorise(mandate, cycle, key)
    send_post_txn(cycle, include_grievance=True)  # clause 7
          

Two details worth stating plainly. The now() - cycle.notified_at check is a guard, not decoration: if the notify job was delayed by a queue backlog, the debit must abort rather than proceed early. And request_afa is not a failure path — above ₹15,000 it is the normal path, so your dunning logic has to distinguish "awaiting customer authentication" from "payment failed", and your churn metrics have to as well.

The same shape applies on UPI Autopay, where NPCI's own rate limits constrain how many mandate executions you can push per second; we covered those ceilings in UPI and NPCI API rate limits under OC-215.

Dispute handling and where liability sits

Clause 9 requires an "appropriate dispute redressal system", and it explicitly pulls in RBI's existing instructions on limiting customer liability for unauthorised transactions: those now apply to recurring e-mandate debits as well. In Agrud Partners' analysis of the framework, the practical effect is that the reporting clock matters — zero customer liability where the issuer is at fault, and a tiered cap where the customer reports a third-party unauthorised transaction after the first few working days, with the burden of proving customer negligence sitting with the issuer.

For an engineering team, that translates into two requirements that are easy to under-build. You need a customer-visible dispute entry point reachable from the post-transaction notification itself, and you need to be able to reconstruct, per debit, exactly when the pre-transaction notification was sent and through which channel. The second one is the evidence you will be asked for, and it is only available if you persisted notified_at at the time rather than inferring it later from logs.

Clause 10(a) is short and absolute: "No charges shall be levied to the customer for availing the e-mandate facility for recurring transactions." A convenience fee on autopay is not available to you.

What was repealed

The framework repeals eight circulars, which is useful because it tells you which internal documents to retire.

If your compliance wiki cites any of those eight by circular number, the citation is now dead. Point it at the 2026 Directions instead.

India-specific considerations

Three practical notes for teams building here.

Acquirer accountability changes your merchant contracts. Clause 10(c) makes the acquirer responsible for merchant compliance. If you are a payment aggregator or a platform onboarding sub-merchants, the opt-out facility and the notification obligations are now yours to enforce contractually and to audit, not just to document. Build the merchant-side compliance check into onboarding rather than discovering it in an annual review. The same distribution-of-responsibility pattern runs through the digital lending rules; we mapped it in the RBI digital lending directions engineering checklist.

Cross-border recurring is explicitly in scope. Clause 2 covers "domestic or cross-border" recurring transactions. Indian card-not-present recurring charges to overseas merchants sit inside this framework and alongside the separate authentication timeline for cross-border card-not-present transactions, which we covered in RBI's authentication directions for cross-border CNP.

Notification content is personal data. The pre-transaction and post-transaction notifications carry merchant name, amount and mandate reference to a phone number or email address. Under the Digital Personal Data Protection Act 2023, that is processing of personal data with a defined purpose, and retaining the full notification body indefinitely for evidentiary comfort is the wrong instinct. Retain the send timestamp, channel and template version, which is what proves compliance with clause 6(a); the message body itself does not need the same retention. The wider obligations sit in our DPDP engineering playbook for Indian startups.

What to do this week

Diff your mandate schema against build items 2 and 4: validity period and customer-set maximum are both required fields and both are commonly missing on older mandates. Add the grievance-redressal field to your post-transaction templates. Confirm with your acquirer, in writing, whether they support clause 10(b) mandate mapping on card reissue, because that one clause is worth more in retained subscriptions than the rest of the framework combined. Then check whether your card-control evaluation path is correctly bypassed for mandate-originated debits under clause 5(b), because a control that silently blocks a renewal produces a support ticket that looks like a payment failure and is not one.

Teams retrofitting AFA into an older payments stack will find the sequencing work covered in our RBI AFA authentication retrofit notes, and the subscription-billing side in app subscription billing and monetisation.

FAQ

How eCorpIT can help

eCorpIT builds payments and subscription systems for Indian fintechs, insurers and D2C platforms, and clause-level work like this is what our senior engineering teams do before a compliance deadline turns into an incident. We map the Directions onto your existing mandate schema, rebuild the notification scheduler so the 24-hour floor is provable rather than assumed, and produce the audit evidence your acquirer will ask for. As an ISO 27001:2022 certified and CMMI Level 5 assessed organisation, we design controls to be inspectable. If you are working through the 2026 framework, talk to us.

References

1. Reserve Bank of India, Digital Payments – E-mandate Framework, 2026, RBI/DPSS/2026-27/396, 21 April 2026.

1. Reserve Bank of India, Digital Payments – E-mandate Framework, 2026 (PDF), 21 April 2026.

1. Reserve Bank of India, Authentication mechanisms for digital payment transactions Directions, 2025, 25 September 2025.

1. Reserve Bank of India, Master Direction on Regulation of Payment Aggregators, 15 September 2025.

1. Agrud Partners, Legal analysis: RBI Digital Payments E-mandate 2026, 30 April 2026.

1. SCC Times, RBI notifies Digital Payments — E-mandate Framework, 2026, 24 April 2026.

1. LexOrbis, RBI's Digital Payments E-mandate Framework, 2026, 2026.

1. Conventus Law, RBI's Digital Payments E-mandate Framework, 2026: consolidated directions for recurring digital transactions, 2026.

1. AMLEGALS, UPI Autopay and recurring payments: compliance checklist under RBI's e-mandate framework 2026, 2026.

1. India Law, RBI e-mandate framework 2026: recurring payments rules, 2026.

1. Taxguru, RBI issues consolidated directions on Digital Payments – E-mandate framework, 2026, 2026.

1. Mondaq, The Digital Payments: E-mandate Framework, 2026 — a consolidated regulatory architecture for recurring transactions, 2026.

Last updated: 6 August 2026.