RBI Card Security and Tokenisation Guidelines
The Reserve Bank of India has put in place a set of card-security rules to reduce fraud in digital payments. These cover authentication, tokenisation, card controls, recurring payments, and customer liability in case of unauthorised transactions.
Regulatory Framework
The RBI draws its powers to regulate payment systems from Section 10(2) and Section 18 of the Payment and Settlement Systems Act, 2007. Its directions apply to payment system operators, card networks, issuing banks, acquiring banks, and merchants. Non-compliance can attract monetary penalties under Section 26 and Section 30 of the Act.
- Coverage: Card-based digital payments, online transactions, recurring payments, and token-based payment storage.
- Objective: Protect payment channels against unauthorised access, data breaches, and fraud.
- Applicability: Rules extend to domestic and cross-border card transactions routed through authorised systems.
Additional Factor of Authentication
The RBI mandates Additional Factor of Authentication (AFA) for all card-not-present transactions made with Indian cards. AFA adds a second layer of verification in which one factor is dynamic, such as an OTP, time-based OTP, or biometric authentication.
- Online card payments: AFA is compulsory for card-not-present transactions.
- Dynamic factor: Usually an OTP sent by SMS, time-based OTP, or biometric confirmation.
- Contactless POS payments: Near Field Communication-based payments do not require a PIN up to ₹5,000.
- Higher value contactless use: Payments above ₹5,000 at physical POS terminals require PIN entry.
Card Controls and Default Safeguards
Banks must provide cardholders with easy controls to manage card usage. These controls help users limit exposure to fraud and allow them to activate only the channels they need.
- On/off facility: Banks must allow debit and credit cards to be switched on or off through mobile apps, internet banking, or ATMs.
- Transaction-wise limits: Cardholders must be able to set spending limits for domestic, international, contactless, ATM, and e-commerce transactions.
- Default restrictions: Newly issued cards must remain disabled by default for international and online card-not-present transactions until activated by the user.
Card-on-File Tokenisation
Card-on-File Tokenisation (CoFT) replaces sensitive card data such as the 16-digit Primary Account Number (PAN), expiry date, and CVV with a unique surrogate value called a token. The token is specific to the actual card, the token requester, and the merchant platform.
Exam fact: Merchants, payment gateways, and payment aggregators cannot store actual card details on their servers. They may store only the token and the last four digits of the card.
- Token Service Providers: Only authorised card networks such as RuPay, Visa, and Mastercard, and card-issuing banks, can act as Token Service Providers (TSPs).
- Purpose: Reduce the exposure of card credentials during online payments.
- Scope: CoFT is used mainly for e-commerce merchant websites and apps.
- Customer consent: Tokenisation requires explicit customer consent validated through AFA.
- Lifecycle update: When a card is renewed, replaced, or upgraded, the token mapping is updated without requiring the user to manually reset details.
Types and Scope of Tokenisation
| Tokenisation Type | Channel / Form Factor | Permitted Entities |
| Device-Based Tokenisation | Smartphones, tablets, smartwatches, and NFC wearables | Authorised 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 |
- Device-based tokenisation: Used for smartphones, tablets, smartwatches, and NFC wearables.
- CoFT on merchant platforms: Used for stored-card e-commerce transactions.
- Issuer-level tokenisation: Banks may enable tokens directly through their own apps and internet banking.
- Guest checkout: Allows tokenisation for one-time purchases without creating an account.
E-Mandate Framework for Recurring Transactions
The RBI framework for recurring payments applies to subscriptions and other periodic debits such as utility bills, insurance premiums, mutual fund investments, and digital subscriptions. Setting up an e-mandate requires initial registration with AFA validation.
- Pre-debit notice: Merchant or bank must send a notification by SMS or email at least 24 hours before the debit.
- Customer choice: The notice must allow the subscriber to opt out of that payment cycle or cancel the mandate.
- Execution rule: For eligible amounts, the transaction may proceed without a fresh dynamic OTP during execution.
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 |
Fraud Mitigation and Customer Liability
The RBI framework also defines liability norms for unauthorised electronic transactions. The customer’s liability depends on the cause of the fraud and the speed of reporting.
- Zero liability: Applies where the unauthorised transaction results from contributory fraud or negligence by the bank, or a third-party breach, and the customer reports it within three working days.
- Limited liability: If reported within four to seven working days, customer liability is capped according to account type.
- Cap for savings accounts: Maximum liability is ₹10,000 for standard savings accounts.
- Cap for credit cards: Maximum liability is ₹25,000 for high-limit credit cards.
- Full liability: If reporting is delayed beyond seven working days, liability follows the bank’s board-approved policy.
- Customer negligence: If the customer shares PIN, OTP, or other credentials, the customer bears the loss until the transaction is reported.
Auto-Reversal and Compensation
Under the RBI’s Turn Around Time (TAT) framework, failed transactions must be reversed within fixed windows, generally ranging from T+1 to T+5 days depending on the system. If a bank fails to reverse an unauthorised or failed transaction within the prescribed TAT, it must pay compensation of ₹100 per day of delay.
Key Prelims Takeaways
- Parent law: Card-security directions flow from the Payment and Settlement Systems Act, 2007.
- AFA: Mandatory for card-not-present transactions using Indian cards.
- Contactless limit: No PIN required up to ₹5,000 for NFC-based POS payments.
- Tokenisation: Replaces actual card data with a unique token linked to the card and merchant.
- Storage rule: Merchants and aggregators cannot store actual card numbers, expiry dates, or CVVs.
- Recurring payments: E-mandates need initial AFA and a 24-hour pre-debit notice.
- Customer liability: Depends on reporting time, bank fault, and customer negligence.