NPCI Makes UPI AutoPay Portable: 7 Big Changes to Know

India's digital payments system just took a major leap forward. The National Payments Corporation of India (NPCI) has upgraded UPI AutoPay. Standard UPI payments for shops and friend-to-friend transfers have always worked across all apps. However, recurring AutoPay setups remained locked inside the specific app where you created them.

UPI AutoPay Portability changes this completely. It separates your automatic payments from any single app. Now, recurring mandates are portable across apps. You can view, manage, and move your active mandates—such as SIPs, insurance premiums, streaming subscriptions, and electricity bills—across any supported UPI app without canceling or restarting them.

The Legacy Paradigm vs. The Interoperable Mandate Framework

Understanding the magnitude of this shift requires a deep dive into the architectural friction that governed recurring digital payments under the legacy framework.

The Legacy Structure (Pre-Interoperability)

In the old system, setting up an AutoPay mandate locked your payment to that specific UPI app's payment handle and ID. This created three big headaches:

App Lock-In: If you set up several recurring debits for EMIs, mutual funds, and subscriptions on one app, you were stuck with it. Switching to a competing UPI application required a high-friction process: manually revoking every active mandate, logging into individual merchant portals, and executing fresh Additional Factor Authentication (AFA) setups on the new app.

• Fragmented Visibility (The "Ghost Mandate" Problem): Users lacked a centralized console across their banking profiles to audit all live recurring obligations. If an application was uninstalled without the user explicitly revoking the underlying mandate within the app interface, automated debits continued at the remitter bank level. This frequently resulted in unexpected debits or failed transaction penalty charges.
• Merchant Gateway Dependence: On the enterprise side, recurring mandates were bound to specific Payment Aggregators (PAs) and Payment Gateways (PGs). If a business attempted to migrate to a more cost-effective or reliable payment processor, it faced massive customer drop-offs because legacy mandates could not be migrated on the backend without forcing the end-user to re-authorize.

The Interoperable Framework

The modernized framework transforms the mandate from an app-specific permission token into an interoperable, portable asset held centrally at the remitter bank and NPCI central switch level. The consumer-facing application now acts merely as an interface layer rather than an exclusive custodian of the data.

Core Pillars of the Interoperability Framework

The updated mandate architecture establishes two functional pillars for all payment ecosystem participants—Remitter Banks, Sponsor Banks, Payment Service Providers (PSPs), and TPAPs.

Pillar 1: Universal Viewability ("View Anywhere")

Under the portability guidelines, all active mandates linked to a user's bank account must be queryable and visible across any compliant UPI application registered with the same verified mobile number, as well as on the central NPCI My Mandates portal.

When a user links their bank account to a new UPI application, the app issues a secure lookup request to the NPCI switch. The switch queries the remitter bank's mandate database and returns a standardized, read-only payload detailing every active standing instruction associated with that account number and VPA. This eliminates the "forgotten subscription" problem, bringing absolute transparency to user cash flows.

Also Read | Green Bonds in India: A Complete Guide to the Market and Regulations

Pillar 2: Mandate Portability ("Seamless Migration")

Users possess the explicit, protected right to migrate the management layer of an active e-mandate from an Originating App (TPAP-A) to a Destination App (TPAP-B). Once ported, all future ecosystem communications—push notifications, pre-debit alerts, pause/resume commands, limit modifications, and explicit cancellations—are handled natively through the newly selected application.

Technical Execution Flow: How Portability Works

The technical workflow for transferring a mandate relies on standardized API parameters defined within the upgraded UPI protocol suite. The process is designed to be frictionless for the user while maintaining bank-grade cryptographic security on the backend.

1. Discovery & Selection: The user opens the destination UPI application, navigates to the mandate management section (often labeled "Manage AutoPay" or "Transfer Autopay"), and the app fetches all active e-mandates linked to the underlying bank account via the NPCI switch.
2. Mandate Review: The user selects the specific mandate targeted for relocation. The application renders the immutable details: the Unique Mandate Reference Number (UMRN), Merchant Name, Maximum Approved Debit Limit, and the Current Associated App.
3. API Request Dispatch: Upon the user initiating the transfer, the destination app issues a `ReqMandate` API call configured with the attribute `type = UPDATE` to the NPCI UPI Switch.
4. Additional Factor Authentication (AFA): The NPCI switch prompts the user to enter their secure UPI PIN. This is the critical security checkpoint. It ensures cryptographic proof of authorization directly with the remitter bank, preventing rogue applications or third parties from silently hijacking mandate routing records in the background.
5. Switch Registry Update: Upon successful PIN validation, the remitter bank updates its internal routing table. The NPCI switch re-binds the UMRN’s notification and management handle to the new destination PSP/TPAP app.
6. Synchronized Handshake: The destination app displays a confirmation status. Simultaneously, an asynchronous webhook update is dispatched to the originating app, compelling it to update its local database and mark the mandate as "Ported Out" or render it in a read-only state.

Architectural Constants vs. Dynamic Variables

A critical security feature of mandate portability is the strict distinction between parameters that remain fixed throughout the transfer and those that change dynamically to facilitate the new routing.

Immutable Parameters (What Does NOT Change)

• The Unique Mandate Reference Number (UMRN): The globally unique, 18-digit alphanumeric identifier generated by NPCI at the time of initial mandate creation remains the permanent anchor.
• The Underlying Remitter Bank Account: The source of funds remains the user’s designated bank account. Porting a mandate changes the software interface managing the mandate, not the underlying funding account.
• Financial Constraints & Caps: The maximum per-debit limit authorized by the user cannot be expanded during a porting event. Modifying execution limits requires an entirely separate, explicit mandate alteration workflow to prevent authorization fraud.
• Merchant Terms & Frequency: The contractual execution date, merchant billing cycle, and end date remain identical.
• Regulatory Pre-Debit Notification: Under Reserve Bank of India (RBI) e-mandate directives, the remitter bank and merchant must continue providing a pre-debit alert via SMS or push notification at least 24 hours prior to the actual execution date.

Mutable Parameters (What Changes)

• Managing PSP/TPAP Routing: Future execution payloads, notification flags, and management calls are routed exclusively through the new application's infrastructure.
• User Control Console: Subsequent lifecycle actions such as pausing, unpausing, or revoking the mandate are executed within the new app’s native user interface.
• Dispute & Grievance Node: If a double-debit or execution failure occurs post-migration, the primary dispute resolution pipeline (via the UPI Help module) is initiated within the newly selected app.

Regulatory Guardrails and Anti-Competitive Protections

To maintain financial system stability and prevent abusive commercial practices, the interoperability framework introduces strict regulatory guardrails governing how and when mandate transfers can occur.

The 90-Day Rolling Window Rule

A single e-mandate, identified by its unique UMRN, can be ported at most once every 90 rolling days.

• System Stability: This prevents high-frequency automated switching between applications that could strain banking core systems and NPCI clearing nodes.
• Churn Control: It stops circular porting workflows driven by short-term user experimentation.
• Enforcement: The timer is tracked centrally at the NPCI switch level. If a user attempts to port a mandate migrated 45 days prior, the switch intercepts and rejects the `ReqMandate` update call with a standardized error code indicating temporary ineligibility.

Also Read | Bank of Baroda Launches UPI Global QR Payments

Strict Anti-Solicitation Framework

NPCI enforces a strict policy prohibiting predatory user acquisition strategies built on mandate harvesting. Payment applications are explicitly forbidden from offering financial inducements—such as cashbacks, scratch cards, reward points, or discount vouchers—to incentivize users to port their AutoPay mandates. Furthermore, apps cannot run targeted push notifications or pop-up banners urging users to transfer active mandates from competing platforms. The porting action must be purely organic and user-initiated. Applications are also strictly barred from using cross-app mandate visibility data for targeted marketing, profiling, or cross-selling without explicit, separate user consent.

Merchant-Side Portability and Backend Decoupling

While consumer-facing app portability forms the visible layer of the ecosystem upgrade, the framework incorporates an equally transformative infrastructure overhaul on the enterprise and merchant side.

The Enterprise Decoupling Problem

Historically, when a digital merchant, insurance provider, or mutual fund platform integrated UPI AutoPay, the resulting mandates were bound to the merchant's chosen Payment Aggregator (e.g., Razorpay, Cashfree, BillDesk). If a merchant wished to switch its payment processing infrastructure due to commercial pricing, technical downtime, or service quality, it faced a severe operational nightmare: legacy mandates could not be transferred across aggregators. Switching payment gateways meant invalidating thousands of recurring subscriptions, forcing the merchant to ask customers to re-authorize their mandates from scratch—a process that inevitably caused high subscription churn and revenue loss.

The Technical Solution: Purpose Code AZ and PAN-Derived MIC

To solve this, the framework introduced structural updates to backend mandate metadata:

• Transition to Purpose Code AZ: Legacy recurring mandates operated under generic Purpose Code 14. Interoperable mandates transition to Purpose Code AZ, signaling to remitter banks and clearing switches that the mandate is entirely processor-agnostic.
• Corporate PAN-Based Merchant Identifier Code (MIC): Instead of identifying the merchant via an aggregator-assigned sub-merchant ID, the new routing structure binds the merchant identity to a standardized Merchant Identifier Code (MIC) derived directly from the merchant's corporate Permanent Account Number (PAN).

With Purpose Code AZ and a PAN-anchored MIC, a merchant can seamlessly migrate its entire pool of active AutoPay mandates from Payment Aggregator A to Payment Aggregator B on the backend. The merchant's system issues a bulk migration update API call storing the updated UMRNs, maintaining execution continuity without requiring end-consumers to re-authenticate. Furthermore, this allows for Automated Gateway Failover. If a primary payment gateway experiences infrastructure downtime during peak execution hours (such as the 1st of the month for SIPs), the merchant can dynamically re-route execution calls through an alternative payment aggregator without transaction drop-offs.

Strategic Impact on the Indian Fintech Ecosystem

The transition to interoperable recurring mandates reshapes competitive dynamics across multiple market participants.

Leveling the Playing Field for Challenger Apps

Prior to portability, market share in the UPI ecosystem exhibited massive concentration, with a few top players controlling the vast majority of transaction volume. A significant portion of this concentration was passively reinforced by recurring mandate lock-in. By decoupling mandates from apps, challenger UPI platforms and bank-led applications can now compete purely on user experience, application speed, security, and integrated financial services, rather than relying on legacy structural barriers to retain users.

Enhancing Subscription Hygiene for Consumers

Consumers gain a single pane of glass to manage their financial commitments. They can audit all recurring obligations in one place and execute frictionless mandate revocations. If a user wishes to cancel a service, they can execute a binding revocation via UPI PIN directly within their active app, terminating the merchant's debit rights at the remitter bank level immediately, eliminating unintended, lingering debits.

Boosting Execution Success Rates for Enterprises

For wealth management platforms, mutual fund houses, and insurance providers, transaction failure rates on recurring debits represent a major operational friction point. Interoperability reduces failures caused by defunct VPAs, dormant app accounts, or stale payment handles. Because mandates are anchored at the remitter bank and route dynamically via the user's active UPI application, execution success rates for high-value recurring transactions improve across the board.

Implementation Realities and Scope Boundaries

While the regulatory framework is clear, ecosystem adoption across India's complex network of banks, aggregators, and applications is progressive. Full mandate interoperability requires all three core nodes—the Remitter Bank, the Sponsor Bank/Aggregator, and both TPAPs—to be fully certified for Purpose Code AZ. If an underlying remitter bank has not yet fully deployed the updated API endpoints, individual mandates linked to that bank may temporarily display as ineligible for transfer.

Clarifying Scope Boundaries (What Cannot Be Ported)

It is crucial to recognize the boundary conditions of this framework. It applies exclusively to e-mandates registered directly on the UPI AutoPay rail (such as UPI-based SIPs, OTT subscriptions, insurance premiums, and utility AutoPay). The following recurring debit mechanisms fall strictly outside this framework and cannot be ported via UPI apps:

• Card-Billed Subscriptions: Recurring payments tied directly to Visa, Mastercard, or RuPay credit/debit card numbers.
• NACH / e-NACH Mandates: Electronic mandates routed via the National Automated Clearing House using IFSC and Account numbers or net banking credentials.
• App Store In-App Subscriptions: Subscriptions managed directly through the Apple App Store or Google Play Store billing engines.
• Digital Wallet Auto-Reloads: Stored-value wallet auto-top-up instructions operating under proprietary internal wallet APIs.

UPI AutoPay Portability represents a foundational milestone in India’s broader Open Banking movement. By ensuring that financial permissions, mandates, and data rights remain anchored strictly to the consumer rather than locked within proprietary application walled gardens, the ecosystem establishes a global benchmark for interoperable digital payment infrastructure. As implementation reaches full maturity, the friction associated with switching digital financial service providers effectively disappears, paving the way for a more competitive, transparent, and consumer-centric financial landscape.

Also Read | UPI Privacy Rules Are Changing: What Happens to Your Mobile Number After September 4?