Card Tokenisation Explained: IIBF Digital Banking 2026 Guide

Every time you save a card on an e-commerce checkout, a quiet piece of security engineering kicks in behind the scenes. That mechanism is card tokenisation, and since October 2022 the Reserve Bank of India has made it the backbone of how merchants handle card-on-file data. For candidates preparing for the IIBF Digital Banking exam, this topic sits at the intersection of payment systems, data security and RBI regulation — exactly the kind of applied concept examiners love. This guide breaks down what tokenisation is, how RBI's Card-on-File Tokenisation (CoFT) framework works, and the exam-ready facts you must remember.

Before we dive in, it helps to place tokenisation within the wider retail-payments landscape covered in the Overview of Digital Banking chapter and the POS (Point of Sale) module, where card acceptance is first introduced.

🔐 What Is Card Tokenisation?

Card tokenisation is the process of replacing a customer's sensitive card credentials — chiefly the 16-digit Primary Account Number (PAN), expiry date and other identifiers — with a unique, algorithmically generated alternate code called a token. This token is meaningless if stolen: it cannot be reverse-engineered back into the original card number, and it is typically restricted to a specific merchant and device combination.

The core idea is data minimisation. Under RBI's framework, merchants, payment aggregators and payment gateways are prohibited from storing actual card details on their servers. Instead, they store only the token. So even if a merchant's database is breached, the attacker gets tokens that are useless elsewhere, dramatically shrinking the value of stolen data.

Tokens are issued by the card networks — Visa, Mastercard, RuPay, American Express and Diners — acting as Token Service Providers (TSPs), or increasingly by the card-issuing bank itself. The mapping between the real card and its token (kept in a secure "token vault") never leaves the trusted network environment. This is conceptually similar to how sensitive data is protected across other channels such as internet and Mobile Banking, where credentials are shielded from the interface layer.

💡 Exam Tip: Remember that a token is device- and merchant-specific by default. The same physical card generates different tokens for different merchants — this is why a leak at one merchant does not compromise the others.

🛠️ How the Tokenisation Process Works

The customer journey is deliberately simple, but four parties work together behind it: the cardholder, the merchant, the card network (TSP), and the issuing bank. When a customer opts to save a card for future use, they must give explicit consent, validated by an Additional Factor of Authentication (AFA) — usually an OTP. Only after this two-step consent can a token be created.

Here is the typical flow:

• Request: At checkout the customer chooses to tokenise the card and enters card details plus OTP.
• Token generation: The card network validates with the issuer and generates a unique token, storing the real-PAN-to-token mapping in its secure vault.
• Storage: The merchant saves only the token (plus, at most, the last four digits and card network name for display).
• Transaction: On future purchases the token is transmitted, de-tokenised inside the network, and the payment is authorised — all without exposing the real card number to the merchant.

Crucially, tokenisation is free for the customer and entirely optional — a customer can always choose to key in the full card number each time. RBI has also enabled tokenisation to be triggered directly through the issuer bank's app or net-banking portal, giving customers a single place to view and manage tokens across merchants.

⚠️ Common Mistake: Candidates often assume tokenisation encrypts the card number. It does not — it substitutes it. Encryption is reversible with a key; a token has no mathematical relationship to the PAN.

📊 Device vs Card-on-File Tokenisation

Two flavours of tokenisation appear in the syllabus, and examiners like to test the distinction. Device tokenisation stores the token on a physical device — your phone's secure element for Google Pay or Apple Pay taps. Card-on-File (CoF) tokenisation replaces the card details a merchant would otherwise save on its server for recurring or one-click payments. RBI's 2022 mandate specifically targeted the card-on-file use case.

Both models share the same regulatory DNA: no actual card data at the merchant, consent with AFA, and network-controlled vaults. The difference is purely where the token lives and which use case it serves. Financial inclusion goals also benefit, because safer digital payments encourage first-time users — a theme explored in the Financial Inclusion chapter.

🏦 RBI Timeline and Regulatory Mandate

Understanding the regulatory chronology helps you answer date-and-milestone questions with confidence. RBI first issued its tokenisation guidelines for card transactions in January 2019, initially permitting only device-based tokenisation. It then extended the framework to card-on-file tokenisation and, after several deadline extensions to give the industry time to comply, made the CoFT mandate effective from 1 October 2022.

From that date, merchants, aggregators and gateways had to purge stored card data and rely on tokens. In 2023, RBI went a step further, allowing customers to create card-on-file tokens directly at the issuer-bank level — through the bank's mobile app or internet banking — rather than only during a merchant checkout. This "CoFT via issuer" route makes token management more transparent and customer-controlled.

📌 Remember: The three pillars RBI insists on are (1) no storage of actual card data by merchants/aggregators, (2) explicit customer consent with AFA, and (3) tokens generated only by authorised card networks or issuers.

For candidates who also sit certification exams, note how this ties into operational-risk and business-continuity thinking — see Business Continuity Planning for CAIIB ITDB for the resilience angle that regulators expect alongside data-security controls.

💡 Why Tokenisation Matters for the Digital Banking Exam

Tokenisation is a high-yield topic because it connects three exam themes at once: payment-system architecture, cyber-security controls, and RBI's consumer-protection agenda. Questions typically probe whether you understand that tokens are merchant-specific, that AFA consent is mandatory, and that the service is free and optional for customers.

It also sits comfortably beside the other modern payment rails you should master. Reading widely across sibling topics builds the mental map examiners reward — start with our guide to prepaid payment instruments, then compare rails via the UPI ecosystem explainer and the open banking in India deep-dive. Together these cover most of the digital-payments weightage.

You can browse the full set of curated notes on the Digital Banking tag hub, and reinforce weak areas with structured practice on the IIBF mock tests. If you are building a full study plan, the JAIIB course pairs these concepts with graded revision.

📚 Official reference: Always verify the latest rules, circulars and thresholds on the Reserve Bank of India (RBI) website before your exam — regulations change and only primary sources are authoritative.

🧠 Practice MCQs: Card Tokenisation

Want chapter-wise mock tests with 100+ MCQs? Start practising free →

🎯 Conclusion

Card tokenisation is a compact but powerful topic: it shows how a single design choice — substituting the card number with a merchant-specific token — protects millions of digital transactions while keeping the customer experience frictionless. Master the RBI timeline, the AFA-consent rule, and the device-versus-CoFT distinction, and you can confidently clear any question the examiner throws at you. Ready to test yourself under exam conditions? Head to the IIBF Digital Banking mock tests or structure your revision with the JAIIB course and turn this knowledge into marks.