Introducing new channels for Card-on-File Tokenisation

 Introducing new channels for Card-on-File Tokenisation

The Reserve Bank of India (RBI) introduced Card-on-File Tokenisation (CoFT) in September 2021, marking a significant step in enhancing the security and efficiency of electronic transactions.

The implementation of CoFT began on October 1, 2022, and its impact has been noteworthy.

To date, more than 56 crore tokens have been generated, facilitating transactions totaling over ₹5 lakh crore.

This demonstrates the widespread adoption and acceptance of tokenisation as a security measure in the digital payment landscape.

Tokenisation has played a crucial role in bolstering transaction security, ensuring that sensitive card details are shielded from potential security breaches.

Additionally, it has contributed to an improved transaction approval rate, making electronic payments smoother and more reliable for both consumers and merchants.

Previously, the creation of Card-on-File (CoF) tokens was primarily the domain of merchants, involving their applications or webpages.

However, there is now a proposal to expand the token creation process directly at the issuer bank level.

 

This proposed measure holds the promise of greater convenience for cardholders, as they will have the option to easily create tokens and link them to their existing accounts with various e-commerce applications.

This step is poised to simplify and streamline the tokenisation process, ultimately benefiting consumers and promoting the adoption of secure digital payments.

RBI is set to issue specific instructions regarding this enhancement, further solidifying its commitment to advancing the security and accessibility of electronic transactions.

Tokenization is the process of converting actual card details into a unique token, while de-tokenization involves converting the token back into the original card details.

Tokenization offers enhanced security for card transactions because it prevents the sharing of actual card details with merchants during transaction processing. Instead, a token representing the card is used, minimizing the risk of sensitive information exposure.

Customers can initiate tokenization by requesting it through an app provided by the token requestor. The request is then sent to the card network, which, with the consent of the card issuer, generates a corresponding token for that specific card, token requestor, and device.

Tokenization is permitted on various consumer devices such as mobile phones, tablets, laptops, wearables, and IoT devices for different use cases, including contactless card transactions, payments through QR codes, and app-based payments.

Tokenization and de-tokenization can be performed by authorized card networks or card issuers. The RBI provides a list of authorized card networks operating in India.

 

In tokenized card transactions, key stakeholders include the merchant, merchant's acquirer, token service provider, token requestor, issuer, and the customer. However, other entities may also participate in the transaction.

Card details, tokens, and relevant information are securely stored by the token service provider, ensuring the safety of customer data. Token requestors must meet international safety and security standards.

Tokenization is not mandatory for customers; they have the choice to decide whether to tokenize their cards. Customers can also select tokenization for specific use cases like contactless, QR code-based, or in-app payments.

Registration for tokenization requires explicit customer consent through Additional Factor of Authentication (AFA), ensuring customers are fully aware and in control of the process.

Customers can set and modify transaction limits for tokenized card transactions, allowing them to customize their security preferences.

Customers can request tokenization for any number of cards, and they are free to use any of the registered cards with the token requestor app for transactions.

 

Additional Reading:

Tokenisation – Card transactions dt.Jan 08, 2019 @ https://www.rbi.org.in/scripts/FS_Notification.aspx?Id=11449&fn=9&Mode=0

Tokenisation – Card Transactions: Permitting Card-on-File Tokenisation (CoFT) Services dt.September 07, 2021 @ https://www.rbi.org.in/Scripts/NotificationUser.aspx?Id=12159&Mode=0

 

MasterCard Issuer-Initiated Tokenization @ https://developer.mastercard.com/mdes-pre-digitization/documentation/use_case/issuer-tokenization/

 

Disclaimer: These views represent my personal perspective and understanding at the moment. As operating guidelines evolve and become more defined, my understanding may also evolve. However, our unwavering commitment remains focused on spreading the Joy of Safe ePayments.

 

Diabetes Care Motivator #DiabetesCareMotivator

 

 

'SafeNet eToken 3500' – New Tool to combat Online Banking fraud. Which Bank will introduce this in India?

Indian bank customers especially internet banking customers are being made aware of the need for efficient security practices.

As the number of internet banking users is on the use, the threats t internet banking too is in on the increase.

It is a cat and mouse game between Indian Banks and the internet fraudsters in the cyberworld.

The most common terms in internet security is the MITM(Man-in the Middle) or MITB (Man in the Browser) scenario.

Safenet, the 'Data Protection Company', as it's punchline, announced the launch of a Comprehensive Solution for Addressing all Risk Levels in Online Banking.

The Solution is 'SafeNet eToken 3500'.

The main differentiator between 'SafeNet eToken 3500'  and its competitors is the ability of eToken 3500 to read transaction data from the web browser and than generates a unique electronic signature that is used to validate the transaction.

Yes,  'SafeNet eToken 3500' , reads the transaction data from the web browser. Well, check out the demo @ Demo

The following are the steps to secure the financial transaction by 'SafeNet eToken 3500'

1. User logs into the Bank's internet banking site by signing with his/her login id and OTP(One time Password) generated by  'SafeNet eToken 3500' .
2. User inputs the Sum of amount tobe transferred along with the Account number.
3. The  'SafeNet eToken 3500'  is to be held to the computer screen and 'SafeNet eToken 3500', reads the amount and the account number.
4. Basing on the same, an Electronic Signature is generated by 'SafeNet eToken 3500'.
5. The Electronic Signature I.e an number is keyed into the Banks internet banking site.
6. If the details tally, the transaction is approved.

The  'SafeNet eToken 3500'  adds an additional security layer to the transaction. The advantage of logging into the banks website with  'SafeNet eToken 3500' , OTP is that the user need not remember his/her password. This frees the banks from investing in Password generation, storing etc job and also ensures that the log-in is safe 100% every time.

Hm, not sure, when this will be introduced in India?

What is (Man in the Middle attack) MITM scenario? 

(Man in the Middle attack) MITM is an attack in the cyberworld, which involves intercepting a communication between two systems.

The motive is to intercept the exchanged data and inject false data. The false data in internet banking can be a change in the intended beneficiary or the amount of the respective transaction.

The man in the middle attack is one in which the attacker intercepts messages in a public key exchange and then retransmits them, substituting his own public key for the requested one, so that the two original parties still appear to be communicating with each other.

How did the (Man in the Middle attack) MITM gets its name?

The attack gets its name from the ball game where two people try to throw a ball directly to each other while one person in between them attempts to catch it. In a man in the middle attack, the intruder uses a program that appears to be the server to the client and appears to be the client to the server.

What are the various techniques to thwart (Man in the Middle attack) MITM?

Popular protection techniques against MITM attacks use authentication tools that are based on:

Public key infrastructures : -

such as:

1. Secret keys (which are usually high information entropy secrets, and thus more secure), or

2. Passwords (which are usually low information entropy secrets, and thus less secure)

3. Latency examination, such as with long Cryptographic hash function calculations that lead into tens of seconds; if both parties take 20 seconds normally, and the calculation takes 60 seconds to reach each party, this can indicate a third party

4. Second (secure) channel verification

5. One-time pads are immune to MITM attacks, assuming the security and trust of the one-time pad.

6. Carry-forward verification

What is (Man in the Browser) MITB  scenario?

In (Man in the Middle attack) MITB, a trojan infects the web browser, and has the ability to modify pages, modify transaction content or insert additional transactions, all in a completely covert fashion invisible to both the user and host application.

Security mechanisms such as SSL/PKI and/or Two or Three Factor Authentication solutions, will not thwart (Man in the Middle attack)  MITB attacks.

The only way to repulse a (Man in the Middle attack)  MitB attack is by utilising transaction verification.

As the (Man in the Middle attack) MitB Trojan works by utilising common facilities provided to enhance Browser capabilities such as Browser helper Objects, Extensions and User scripts etc., it is therefore virtually undetectable to virus scanning software.

In an example exchange between user and host, e.g. an Internet banking transaction such as a funds transfer, the customer will always be shown, via confirmation screens, the exact payment information as keyed into the browser. The bank, however, will receive a transaction with materially altered instructions, i.e. a different destination account number and possibly amount. T

Authentication, by definition, is concerned with the validation of identity credentials. This should not be confused with transaction verification. Transaction Verification has to be done by an Out of Band (OOB) mechanism to counter (Man in the Middle attack) MITB attacks.