RBI Guidelines and Circulars on Card Security, Tokenisation and Customer Authentication
The Reserve Bank of India regulates digital payment safety under the Payment and Settlement Systems Act, 2007. The central bank mandates specific technical controls for card payments. These rules cover Additional Factor of Authentication, Card-on-File Tokenisation, device binding, and recurring transaction frameworks. These instructions protect digital payment channels against unauthorized access, data breaches, and payment fraud across domestic and cross-border networks.
Regulatory Architecture for Card Security
Statutory Powers
- The Reserve Bank of India derives powers to regulate payment systems from Section 10(2) and Section 18 of the Payment and Settlement Systems Act, 2007.
- Directions issued by the RBI apply to all authorized payment system operators, card networks, acquiring banks, issuing banks, and online merchants.
- Non-compliance with card security directives attracts monetary penalties under Section 26 and Section 30 of the parent Act.
Additional Factor of Authentication (AFA)
- The RBI mandates an Additional Factor of Authentication for all card-not-present (online) transactions processed with Indian cards.
- AFA requires a two-factor validation method where one factor is dynamic, such as a One-Time Password sent via SMS, time-based OTP, or biometric authorization.
- Contactless card payments through Near Field Communication at Point of Sale terminals do not require a PIN for amounts up to ₹5,000.
- Payments above ₹5,000 at physical POS machines require the cardholder to enter the PIN.
Card Control Mandates
- Banks must provide cardholders with the facility to switch their debit or credit cards on or off via mobile apps, internet banking, or ATMs.
- Issuers must enable cardholders to set transaction-wise spending limits for domestic, international, contactless, ATM, and e-commerce transactions.
- All newly issued cards must come disabled by default for international and online card-not-present transactions until the user explicitly activates them.
Card-on-File Tokenisation (CoFT)
Tokenisation Mechanism
- Card-on-File Tokenisation replaces actual 16-digit Primary Account Numbers (PAN), expiry dates, and CVVs with a unique alternate code called a “Token”.
- A token is unique to a specific combination of the actual card, the token requester (merchant app), and the identified merchant platform.
- Merchants, payment gateways, and payment aggregators cannot store actual card details on their servers; they can only store the token and the last four digits of the card.
- Only authorized card networks (such as RuPay, Visa, and Mastercard) and card-issuing banks act as Token Service Providers (TSPs).
Types and Scope of Tokenisation
| Tokenisation Type | Channel / Form Factor | Permitted Entities |
| Device-Based Tokenisation | Smartphones, tablets, smartwatches, and NFC wearables | Authorized Token Service Providers and device OEMs |
| Card-on-File Tokenisation (CoFT) | E-commerce merchant websites and applications | Card networks, issuing banks, and registered merchants |
| CoFT at Issuer Level | Bank mobile applications and internet banking portals | Card-issuing banks directly enabling tokens for merchants |
| Guest Checkout Tokenisation | One-time checkouts on merchant websites without account creation | Card networks via payment aggregators |
Customer Consent and Lifecycle Controls
- Tokenisation requires explicit customer consent via an Additional Factor of Authentication validation.
- Card issuers must provide a central portal or mobile dashboard where cardholders can view, suspend, resume, or delete active tokens linked to their cards.
- When a card is renewed, replaced, or upgraded, the token service provider updates the underlying token mapping without requiring manual changes by the user.
E-Mandate Framework for Recurring Transactions
Operational Rules for Subscriptions
- The RBI framework for recurring transactions covers periodic charges such as utility bills, insurance premiums, mutual fund investments, and digital subscriptions.
- Setting up an e-mandate requires an initial registration with AFA validation.
- The merchant or bank must send a pre-debit notification via SMS or email at least 24 hours before debiting the account.
- The notification must provide the subscriber an option to opt out of that specific payment cycle or cancel the entire mandate.
E-Mandate Limit Thresholds
| Transaction Category | Old Limit (Per Transaction) | Current Limit (Per Transaction) | Authentication Rule |
| General Subscriptions | ₹5,000 | ₹15,000 | No separate AFA needed during execution if below limit |
| Mutual Fund Inflows | ₹15,000 | ₹1,00,000 | Exemption from additional dynamic OTP up to limit |
| Insurance Premiums | ₹15,000 | ₹1,00,000 | Exemption from additional dynamic OTP up to limit |
| Education Fee Payments | ₹15,000 | ₹1,00,000 | Exemption from additional dynamic OTP up to limit |
Guidelines on Fraud Mitigation and Customer Liability
Limiting Customer Liability
- Zero Liability: The customer has zero liability for unauthorized electronic transactions caused by contributory fraud or negligence by the bank, or third-party breaches where the customer reports the incident within three working days.
- Limited Liability: If the customer reports an unauthorized transaction within four to seven working days, the customer liability is capped based on the account type (maximum ₹10,000 for standard savings accounts and ₹25,000 for high-limit credit cards).
- Full Liability: If the customer delays reporting beyond seven working days, liability is determined per the board-approved policy of the respective bank.
- Customer Negligence: If the customer compromises credentials (such as sharing PIN or OTP), the customer bears the entire loss until the unauthorized transaction is reported to the bank.
Auto-Reversal Timeframes (Harmonisation of Turn Around Time)
- Under RBI’s Turn Around Time (TAT) framework, failed transactions must be reversed within fixed operational windows (designated as T+1 to T+5 days depending on the system).
- If a bank fails to reverse an unauthorized or failed transaction within the prescribed TAT, it must pay compensation of ₹100 per day of delay to the customer.
Important Facts for Revision
- The Payment and Settlement Systems Act of 2007 provides the statutory backing for all RBI circulars on card safety and tokenisation.
- Tokenisation replaces the 16-digit card number with a unique surrogate value called a token.
- A token is tied to a specific merchant, customer device, and token requester; it cannot work on other platforms.
- Only card networks and card-issuing banks can function as authorized Token Service Providers.
- Merchants and payment aggregators are barred from saving actual card data on their databases.
- Contactless payments via NFC at POS terminals do not require a PIN for amounts up to ₹5,000.
- For recurring e-mandates on mutual funds, insurance premiums, and educational fees, the per-transaction limit without fresh OTP validation is ₹1,00,000.
- For general e-mandate subscriptions, the per-transaction limit without fresh OTP validation is ₹15,000.
- Banks must deliver a pre-debit SMS or email alert to the cardholder at least 24 hours prior to processing a recurring transaction.
- Zero customer liability applies if an unauthorized digital transaction is reported to the bank within three working days.
- Issuing banks must provide customers the ability to modify transaction limits and toggle specific payment channels on or off.
- Banks must pay a compensation penalty of ₹100 per day if they fail to reverse failed card or ATM transactions within the prescribed Turn Around Time.
Originally written on
December 19, 2015
and last modified on
August 18, 2026.