Encryption vs tokenization: what's the difference?
Encryption transforms data; tokenization replaces it. How they compare with masking and hashing, how RBI card tokenisation works, and what to use for student and fee data.
On this page 11 sections
Encryption scrambles data with a key, so anyone who obtains the key can turn it back; tokenization swaps the data for a random stand-in, a token, and keeps the real value in a separate, tightly guarded vault, so the token on its own reveals nothing. Use encryption for data your systems must read or move, and tokenization for a few high-value fields, such as card numbers, that most of your systems never need to see. In India, card tokenization is effectively compulsory: RBI rules bar merchants from storing customers' actual card numbers.
Encryption: reversible with a key
Encryption runs data through a published algorithm, such as AES, controlled by a secret key. The output looks random, but it is still the original data in scrambled form, and anyone holding the key can reverse it.
- It scales to anything: single fields, whole databases, backups, video files and network traffic.
- Its security is the key's security. If the key leaks along with the data, the protection is gone. Every system that needs to read the data needs access to the key, which is where real failures tend to happen; see our guide to encryption key management.
- A variant, format-preserving encryption, keeps the output in the same shape as the input, so a 16-digit number encrypts to another 16-digit number. It helps older systems that validate formats, at the cost of more complex cryptography.
Encryption also differs by where it applies, which our guide to encryption at rest vs in transit covers.
Tokenization: a stand-in value
Tokenization replaces a sensitive value with a token that has no mathematical relationship to it. The real value is stored in a token vault, and only that vault, under strict access control, can map a token back. The RBI's 2019 circular on card tokenisation describes it simply as replacing actual card details with a unique alternate code called the token.
A typical flow:
- A student saves a card at checkout. The card number goes through the payment gateway to the card network's token service, never into your database.
- The service stores the real number and returns a token.
- Your systems store and pass around only the token.
- For the next payment, the token is sent back and only the token service swaps it for the real number.
The strength of tokenization is that the systems holding tokens hold nothing worth stealing. A database breach at the merchant leaks tokens, not card numbers. Under the RBI's rules, a card token is also unique to the combination of card, token requestor and merchant, so a token taken from one merchant is useless at another.
The trade-offs: the vault becomes a single, very valuable target and a dependency for every transaction; each detokenisation adds a network call; and tokens suit a few discrete fields, not bulk data such as documents or videos.
Masking and hashing
Masking
Masking shows only part of a value, such as 98XXXXXX21 or a card's last four digits. The full value exists elsewhere; the person looking at the screen or report just can't see it. Masking can be applied when copies are made, for exports and test databases, or at display time, depending on who is looking. The RBI explicitly allows merchants to keep a card's last four digits and the issuer's name for tracking and reconciliation, which is masking in practice.
Hashing
Hashing turns a value into a fixed fingerprint that can't be reversed, which is right for passwords when done with a slow, salted algorithm; see our guide to password hashing. It is a poor way to protect values with few possible inputs.
A worked example: a ten-digit mobile number has at most ten billion possible values. An attacker with a leaked table of plain SHA-256 hashes of phone numbers can simply hash every possible number and compare. At an illustrative 100 million hashes a second, that takes under two minutes. If you need to look records up by phone number without storing it in plain text, use a keyed hash, an HMAC with a secret key held separately, and encrypt the actual number for when you need to send an OTP.
Encryption vs tokenization vs masking vs hashing
| Aspect | Encryption | Tokenization | Masking | Hashing |
|---|---|---|---|---|
| Reversible? | Yes, with the key | Only through the vault | No, for the masked copy | No, though guessable inputs can be brute-forced |
| Keeps the format? | Only with format-preserving encryption | Often | Partly | No |
| Best for | Files, databases, backups, traffic | Card numbers and IDs few systems need | Staff screens, receipts, exports | Passwords, integrity checks, lookup indexes (keyed) |
| If the protected copy is stolen | Safe only if the key wasn't stolen too | Tokens alone are worthless | Only the visible part leaks | Safe for strong passwords with slow hashes; not for phone numbers |
Our explainer on encoding vs encryption vs hashing covers the difference between the last three ideas in more depth.
Card tokenization in India
The Reserve Bank of India built its card rules in stages:
- January 2019: an RBI circular on card tokenisation allowed card networks to offer tokenisation to any app, for device-based payments such as contactless, QR and in-app payments, beyond the single use case permitted earlier. Registration needs the customer's explicit consent with an additional factor of authentication, not a pre-ticked box, and the RBI said customers must not be charged for it.
- August 2021: the permitted devices were extended to laptops, desktops, wearables and connected devices.
- September 2021: the card-on-file tokenisation circular extended tokens to cards saved with merchants, allowed card issuers as well as networks to act as token service providers, and said that no entity in the card payment chain other than card issuers and networks shall store actual card data, with previously stored data to be purged.
- December 2021: the deadline for merchants to stop storing card data was extended to 30 June 2022, and industry was asked to find other ways to handle recurring payments, EMIs and chargebacks that had relied on stored card numbers.
Cardholders can see which merchants hold a token for their card through their issuer, and de-register any of them. For an institute collecting fees online, the practical meaning is simple: you should never see or store students' card numbers. Your payment gateway and the card networks handle tokens; your records should hold the gateway's payment references and, at most, the last four digits. Our guide to payment gateway charges in India covers choosing a gateway.
Choosing for student and payment data
Most institutes hold a mix of data with very different needs. A suggested starting point:
| Data | Suggested protection | Why |
|---|---|---|
| Card details | Don't store them; rely on gateway and network tokens | RBI rules, and nothing to steal |
| Passwords | Slow, salted hash such as bcrypt or Argon2id | Never needs to be read back |
| Phone numbers and emails | Encrypt at rest, keyed hash for lookups, mask on most staff screens | Needed for OTPs and messages, but few staff need the full value |
| Government ID numbers | Avoid collecting them; if you must, keep only what you need, such as the last four digits, or tokenise | High harm if leaked |
| Marks, attendance, test results | Encryption at rest plus role-based access | Many systems and staff need to read them |
| Lead lists in the CRM | Mask numbers for telecallers; reveal on demand, with logging | Stops a departing employee walking off with the list |
| Exports and backups | Encrypt the files; limit who can export | Exports are a common way for data to escape |
A worked example: the counselling desk
Take an illustrative admissions team of eight telecallers working through 2,000 new leads a month. If every telecaller sees full phone numbers and can export the lead list, one resignation can take a year's marketing spend to a rival institute. With masking, the screen shows 98XXXXXX21, the "Call" button dials through the CRM without revealing the number, each individual reveal is logged, and bulk exports need a manager's approval. Nobody's work gets harder, but copying the list becomes visible and difficult.
The law points the same way. India's Digital Personal Data Protection Rules, 2025, notified in November 2025, list "encryption, obfuscation, masking or the use of virtual tokens" among the minimum security safeguards expected of organisations that handle personal data, in Rule 6, which takes effect in May 2027. Our DPDP Act compliance checklist covers the rest.
This is general information, not legal advice. For your situation, speak to a lawyer.
Key takeaways
- Encryption transforms data and can be reversed with the key; tokenization replaces data and can only be reversed through the vault.
- Encryption suits bulk data and data many systems use; tokenization suits a few sensitive fields most systems never need.
- Masking limits what people see; hashing suits passwords, but not low-variety values such as phone numbers.
- In India, merchants may not store actual card numbers; card tokens are unique to each card and merchant.
- Match the protection to each field, and treat exports and staff screens as common leak points.
Frequently asked questions
Is tokenization the same as encryption?
No. Encryption mathematically transforms data with a key, and anyone with the key can reverse it. Tokenization replaces data with a random token that has no mathematical link to the original, which is stored in a separate vault. Stealing encrypted data plus its key exposes everything; stealing tokens exposes nothing unless the vault is also breached. Many systems use both, encrypting the vault itself.
Is tokenization reversible?
Only through the tokenisation system. The token vault keeps the mapping between each token and the real value, so authorised systems can ask it to detokenise. Without access to the vault, a token can't be turned back, because there is no key or formula to apply. For cards in India, only the card network or issuing bank acting as the token service provider can recover the actual card number.
What is tokenization in banking?
In banking and payments, tokenization means replacing a card number, and sometimes other account details, with a token that merchants, apps and devices use instead. In India, it follows RBI rules: the token is unique to the card, the requesting app and the merchant, it is created only with the cardholder's consent and an additional authentication step, and merchants may not store actual card numbers.
What is tokenization of debit card?
It is the same process for debit cards as for credit cards. When you save a debit card with a merchant or payment app in India, you consent with an extra authentication step, such as an OTP, and the card network or bank issues a token for that card and merchant. The merchant stores the token, never your card number, and you can de-register it through the merchant or your bank.