Data Masking and Tokenisation in Banks: IIBF IT Security Guide

Every core banking system stores fields that must never travel or sit in the clear — card numbers, account numbers, PAN, Aadhaar, salary and KYC records. Data masking and tokenisation are the two controls the IIBF IT Security paper expects you to separate cleanly, because they solve the same confidentiality problem in very different ways. This guide covers what each technique actually does, where Indian banks deploy them, the audit evidence an examiner will ask for, and the traps that catch candidates who treat both as synonyms for encryption.

🔐 What Data Masking and Tokenisation Mean in Banking

Data masking replaces a sensitive value with a realistic but fictitious one, so the record stays usable for testing, training or analytics while the real identity is gone. A masked account number still looks like an account number, still passes format validation, and still joins correctly across tables — but it points to nobody.

Tokenisation replaces the value with a surrogate called a token. The token has no mathematical relationship to the original value; it can only be mapped back through a protected token vault or a token service. Steal the token database and you have gained nothing, because the mapping lives elsewhere under separate custody.

That is the first thing to fix in your head: encryption is a reversible mathematical transformation governed by a key, whereas tokenisation is a lookup substitution governed by a vault, and masking is usually a one-way, deliberately irreversible transformation for non-production use.

ISO/IEC 27001:2022 recognises data masking as an explicit Annex A control, sitting alongside access restriction and data leakage prevention. Indian obligations reinforce it: the Digital Personal Data Protection Act, 2023 makes the bank a data fiduciary responsible for reasonable security safeguards over personal data, and RBI's Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices expects data confidentiality controls to be documented, owned and independently assured.

Neither control can be applied until the bank knows which fields are sensitive. That is a classification exercise, and it follows the same discipline set out in asset classification and controls. If your data dictionary does not flag the field, no masking engine will protect it — which is exactly how many of the IT security threats in banks convert a minor misconfiguration into a reportable data breach.

💡 Exam Tip: If a question says the original value must be recoverable for a business process, the answer is tokenisation or encryption — never masking. If it says the data is going to a test environment or an outsourced analytics team, the answer is masking.

🧩 Masking vs Tokenisation vs Encryption: The Table to Memorise

Most marks in this area are lost on a single confusion — whether the original value can be brought back, and what you need in order to bring it back. Learn the comparison as a grid rather than as prose.

Two secondary distinctions are worth carrying into the hall. First, format-preserving techniques keep the length and character set of the field intact, which is why legacy applications can consume tokenised or masked values without schema changes. Second, hashing is not on this list because a hash is one-way and, for a low-entropy field like a mobile number, is trivially reversible by brute force unless salted — so hashing alone is not an acceptable substitute for data masking and tokenisation of customer identifiers.

Also note the scope difference. Encryption protects a whole file, column or channel; tokenisation and masking act at field level. That is why a bank can tokenise the card number and still leave the transaction amount, merchant name and timestamp fully readable for analytics — the business keeps its data, the attacker gets nothing of value.

🏦 Where Indian Banks Actually Deploy These Controls

Four deployment patterns cover almost every question the examiner can frame.

Non-production environments

Development, UAT and training systems are the classic leak. They hold production-quality data with production-grade sensitivity but development-grade access control. Static masking during the refresh job is the standard answer, and the refresh procedure itself must be a controlled step covered by controls in software development and maintenance.

Card-on-file tokenisation

Under RBI's card-on-file tokenisation framework, merchants and payment aggregators may no longer store actual card credentials; they store a token instead, generated by the card network or by the card issuer acting as token service provider. The token is typically device-and-merchant specific, so a token stolen from one merchant cannot be replayed at another.

Screens, reports and exports

Dynamic masking limits what a branch user, a contact-centre agent or an outsourced back-office operator can see. PCI DSS reinforces this for cards: where there is no documented business need, the displayed primary account number must be masked so that at most the first six and last four digits remain visible.

Data lakes and analytics

Warehouses aggregate everything, which makes them the highest-value target in the bank. Masking at ingestion plus tokenised join keys lets analysts work without ever holding identifiers. These pipelines still need the underlying platform hardening described for database security in banks, because data masking and tokenisation reduce the value of stolen data — they do not stop the theft.

⚠️ Common Mistake: Assuming tokenisation removes a system from audit scope entirely. It removes the tokenised field from scope; the token vault, the detokenisation API and everyone entitled to call it move firmly into scope, usually at a higher control tier than the system you just simplified.

🛡️ Governance, Controls and the Audit Evidence Examiners Expect

A masking or tokenisation project is a governance exercise wearing a technical costume. The control set an auditor will test is predictable, so learn it as a checklist:

1. Policy and ownership — a data protection standard naming which classes of data must be masked, tokenised or encrypted, with a named data owner per field.
2. Segregation of duties — the team that administers the token vault must not be the team that consumes tokens, and neither should approve its own access.
3. Detokenisation logging — every call that resolves a token back to a real value is logged, retained and reviewed. Unreviewed logs are the single most common audit finding here.
4. Vault resilience — the vault is now a single point of failure for live payments, so it inherits availability requirements. Design it with the redundancy principles from a fault tolerant system.
5. Third-party assurance — where the token service is outsourced, contractual security clauses, right to audit and breach-notification timelines must be explicit.

All of this sits inside the wider framework of organisational security and risk management, and it maps cleanly onto the preventive, detective and corrective taxonomy you revised in types of security controls in banks. Masking is preventive, detokenisation logging is detective, and vault key rotation after a suspected compromise is corrective.

The same logic travels across the syllabus. A broking arm protecting client codes and bank details faces an almost identical control question, which is why the operational discipline described in risk in stock broking operations is worth reading alongside this topic. For supervisory developments that change these expectations, track IIBF and RBI updates through the exam cycle.

📌 Remember: Data masking and tokenisation reduce the impact of a breach. They do not reduce its likelihood. Access control, patching and monitoring still carry that job — say so in any descriptive answer and you will pick up the reasoning mark.

📎 Always cross-check the current text of the governing circular on the CERT-In website before you rely on it in the exam hall or at your desk.

🧠 Practice MCQs: Data Masking and Tokenisation

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

❓ Frequently Asked Questions

Treat this topic as a decision tree rather than a set of definitions, and it becomes one of the easiest scoring areas in the paper. Revise the surrounding controls through the IT Security article hub, then test yourself under time pressure — structured chapter tests and full mocks are available inside the CAIIB and IIBF certification course packs, and consistent practice on data masking and tokenisation scenarios is what converts recognition into marks on exam day.