Tokenisation in card transactions
8-Jan-2019: Tokenisation – Card transactions
Continuing the efforts to improve safety and security of card transactions, Reserve Bank of India had permitted card networks for tokenisation in card transactions for a specific use case.
It has now been decided to permit authorised card payment networks to offer card tokenisation services to any token requestor (i.e., third party app provider), subject to the conditions listed in Annex 1. This permission extends to all use cases / channels [e.g., Near Field Communication (NFC) / Magnetic Secure Transmission (MST) based contactless transactions, in-app payments, QR code-based payments, etc.] or token storage mechanisms (cloud, secure element, trusted execution environment, etc.). For the present, this facility shall be offered through mobile phones / tablets only. Its extension to other devices will be examined later based on experience gained.
All extant instructions of Reserve Bank on safety and security of card transactions, including the mandate for Additional Factor of Authentication (AFA) / PIN entry shall be applicable for tokenised card transactions also.
All other instructions related to card transactions shall be applicable for tokenised card transactions as well. The ultimate responsibility for the card tokenisation services rendered rests with the authorised card networks.
No charges should be recovered from the customer for availing this service.
Before providing card tokenisation services, authorised card payment networks shall put in place a mechanism for periodic system (including security) audit at frequent intervals, at least annually, of all entities involved in providing card tokenisation services to customers. This system audit shall be undertaken by empanelled auditors of Indian Computer Emergency Response Team (CERT-In) and all related instructions of Reserve Bank in respect of system audits shall also be adhered to. A copy of this audit report shall be furnished to the Reserve Bank, with comments of auditors on deviations, if any, from the conditions listed in Annex 1, along with the compliance thereto. Further, a report on the details provided in Annex 2 shall be submitted at monthly intervals to the Chief General Manager, Reserve Bank of India, Department of Payment and Settlement Systems, Central Office, Mumbai and by email.
This directive is issued under Section 10 (2) read with Section 18 of Payment and Settlement Systems Act, 2007 (Act 51 of 2007).
Card tokenisation services: Tokenisation refers to replacement of actual card details with an unique alternate code called the “token”, which shall be unique for a combination of card, token requestor and device (referred hereafter as “identified device”).
Conditions
Tokenisation – de-tokenisation service
i. Tokenisation and de-tokenisation shall be performed only by the authorised card network and recovery of original Primary Account Number (PAN) should be feasible for the authorised card network only. Adequate safeguards shall be put in place to ensure that PAN cannot be found out from the token and vice versa, by anyone except the card network. Integrity of token generation process shall be ensured at all times.
ii. Tokenisation and de-tokenisation requests should be logged by the card network and available for retrieval, if required.
iii. Actual card data, token and other relevant details shall be stored in a secure mode. Token requestors shall not store PAN or any other card detail.
Certification of systems of card issuers / acquirers, token requestors and their app, etc.
iv. Card network shall get the token requestor certified for (a) token requestor’s systems, including hardware deployed for this purpose, (b) security of token requestor’s application, (c) features for ensuring authorised access to token requestor’s app on the identified device, and, (d) other functions performed by the token requestor, including customer on-boarding, token provisioning and storage, data storage, transaction processing, etc.
v. Card networks shall get the card issuers / acquirers, their service providers and any other entity involved in payment transaction chain, certified in respect of changes done for processing tokenised card transactions by them.
vi. All certification / security testing by the card network shall conform to international best practices / globally accepted standards.
Registration by customer
vii. Registration of card on token requestor’s app shall be done only with explicit customer consent through Additional Factor of Authentication (AFA), and not by way of a forced / default / automatic selection of check box, radio button, etc.
viii. AFA validation during card registration, as well as, for authenticating any transaction, shall be as per extant Reserve Bank instructions for authentication of card transactions.
ix. Customers shall have option to register / de-register their card for a particular use case, i.e., contactless, QR code based, in-app payments, etc.
x. Customers shall be given option to set and modify per transaction and daily transaction limits for tokenised card transactions.
xi. Suitable velocity checks (i.e., how many such transactions will be allowed in a day / week / month) may be put in place by card issuers / card network as considered appropriate, for tokenised card transactions.
xii. For performing any transaction, the customer shall be free to use any of the cards registered with the token requestor app.
Secure storage of tokens
xiii. Secure storage of tokens and associated keys by token requestor on successful registration of card shall be ensured.
Customer service and dispute resolution
xiv. Card issuers shall ensure easy access to customers for reporting loss of “identified device” or any other such event which may expose tokens to unauthorised usage. Card network, along with card issuers and token requestors, shall put in place a system to immediately de-activate such tokens and associated keys.
xv. Dispute resolution process shall be put in place by card network for tokenised card transactions.
Safety and security of transactions
xvi. Card network shall put in place a mechanism to ensure that the transaction request has originated from an “identified device”.
xvii. Card network shall ensure monitoring to detect any malfunction, anomaly, suspicious behaviour or the presence of unauthorized activity within the tokenisation process, and implement a process to alert all stakeholders.
xviii. Based on risk perception, etc., card issuers may decide whether to allow cards issued by them to be registered by a token requestor.
Public Credit Registry (PCR)
23-Dec-2018: RBI shortlists TCS, Wipro, IBM, 3 others for setting up Public Credit Registry
The Reserve Bank of India has shortlisted six major IT companies, including TCS, Wipro and IBM India, to set up a wide-based digital Public Credit Registry (PCR) for capturing details of all borrowers and wilful defaulters.
The proposed PCR will also include data from entities like market regulator Sebi, the corporate affairs ministry, Goods and Service Tax Network (GSTN) and the Insolvency and Bankruptcy Board of India (IBBI) to enable banks and financial institutions to get a 360-degree profile of the existing as well as prospective borrowers on a real-time basis.
Consequent to the publication of expression of interest (EOI) on October 27, 2018, the Reserve Bank had received responses from several vendors for implementation of end-end solution for PCR. After evaluating the responses of the interested vendors, the RBI said it has been decided to shortlist the six firms.
The other three shortlisted vendors are: Capgemini Technology Services India, Dun & Bradstreet Information Services India, and Mindtree Ltd.
The RBI would soon seek request for proposal from the six vendors.
In June this year, the RBI had announced to set up a PCR for India to address information asymmetry, foster access to credit and strengthen the credit culture in the economy.
Earlier, a high-level task force was constituted by the RBI to review the current availability of information on credit, the adequacy of the existing information utilities, and to identify gaps that could be filled by a PCR.
In essence, PCR will be a digital registry of authenticated granular credit information and will work as a financial information infrastructure providing access to various stakeholders and enrich the existing credit information ecosystem.
The PCR would be the single point of mandatory reporting for all material events for each loan, notwithstanding any threshold in the loan amount or type of borrower.
Currently, there are multiple granular credit information repositories in India, with each having somewhat distinct objectives and coverage.
Within the RBI, CRILC is a borrower-level supervisory dataset that keeps record of loans of Rs 5 crore and above.
Also, there are four privately owned credit information companies (CICs) operating in India. The RBI has mandated all its regulated entities to submit credit information individually to all four CICs.
According to the EOI, the proposed solution should allow easy integration with ancillary information sources, such as the Ministry of Corporate Affairs, Sebi, GSTN, CERSAI, utility billers, Central Fraud Registry and Wilful Defaulter/Caution/Suit Filed Lists.
Besides, borrowers would also be able to access their own credit information and seek corrections to the credit information reported on them.
Setting up of the PCR assumes significance amid rising bad loans in the financial system. The non-performing assets in the banking system stand at about Rs 10 lakh crore.
4-Nov-2018: RBI starts process to set up digital Public Credit Registry for capturing all details of borrowers
The Reserve Bank has initiated steps to set up a wide-based digital Public Credit Registry (PCR) to capture details of all borrowers, including wilful defaulters and also the pending legal suits in order to check financial delinquencies. The PCR will also include data from entities like market regulator Sebi, the corporate affairs ministry, Goods and Service Tax Network (GSTN) and the Insolvency and Bankruptcy Board of India (IBBI) to enable the banks and financial institutions to get 360 degree profile of existing and prospective borrowers on a real-time basis. The Reserve Bank has invited expression of interest (EOI) for developing the registry from companies with a turnover of over Rs 100 crore in the last three years.
In June this year, the RBI had announced to set up a PCR for India with a view to address information asymmetry, foster access to credit and strengthen the credit culture in the economy.
Earlier, a high-level task force (HTF) was constituted by the RBI to review the current availability of information on credit, the adequacy of the existing information utilities, and identify gaps that could be filled by a PCR.
In essence, PCR will be a digital registry of authenticated granular credit information and will work as a financial information infrastructure providing access to various stakeholders and enrich the existing credit information ecosystem. The PCR would be the single point of mandatory reporting for all material events for each loan, notwithstanding any threshold in the loan amount or type of borrower.
Currently, there are multiple granular credit information repositories in India, with each having somewhat distinct objectives and coverage. Within the RBI, CRILC is a borrower level supervisory dataset with a threshold in aggregate exposure of Rs 5 crore. Also there are four privately owned credit information companies (CICs) operating in India. The RBI has mandated all its regulated entities to submit credit information individually to all four CICs.
As per the EOI, the proposed solution should allow easy integration with ancillary information sources, like the Ministry of Corporate Affairs, Sebi, GSTN, CERSAI, utility billers, Central Fraud Registry and Wilful Defaulter/Caution/Suit Filed Lists.
Besides, borrowers would also be able to access their own credit information and seek corrections to the credit information reported on them.
Setting up of the PCR assumes significance amidst rising bad loans in the financial system. The non-performing assets in the banking system is about Rs 10 lakh crore.
Society for Worldwide Interbank Financial Telecommunication (SWIFT)
11-Dec-2018: SWIFT India appointed ex-SBI chief Arundhati Bhattacharya as the new chairman of its board.
SWIFT Indi has appointed ex-SBI chief Arundhati Bhattacharya as the new chairman of its board.
SWIFT India is a joint venture of top Indian public and private sector banks and SWIFT (Society for Worldwide Interbank Financial Telecommunication).
Bhattacharya will succeed former banker M V Nair, who is stepping down after completing five years with the company.
The company was created to deliver high quality domestic financial messaging services to the Indian financial community.
Bhattacharya said the venture has a huge potential to contribute significantly to the financial community in many domains.
19-Nov-2018: warning to SWIFT by U.S. Treasury Steven Mnuchin
The Head of the US Treasury Steven Mnuchin has announced that Washington wants the world-wide payment network to cut off its services to the entities that were affected by Iran sanctions and warned that otherwise SWIFT might be sanctioned as well.
The US will reintroduce sanctions against Tehran that were earlier lifted under the Iran nuclear deal, on November 5. These sanctions will affect the country’s energy, banking, and shipping sectors.
What is SWIFT?
The SWIFT is a global member-owned cooperative that is headquartered in Brussels, Belgium. It was founded in 1973 by a group of 239 banks from 15 countries which formed a co-operative utility to develop a secure electronic messaging service and common standards to facilitate cross-border payments. It carries an average of approximately 26 million financial messages each day. In order to use its messaging services, customers need to connect to the SWIFT environment.
Functions: SWIFT does not facilitate funds transfer: rather, it sends payment orders, which must be settled by correspondent accounts that the institutions have with each other. The SWIFT is a secure financial message carrier — in other words, it transports messages from one bank to its intended bank recipient. Its core role is to provide a secure transmission channel so that Bank A knows that its message to Bank B goes to Bank B and no one else. Bank B, in turn, knows that Bank A, and no one other than Bank A, sent, read or altered the message enroute. Banks, of course, need to have checks in place before actually sending messages.
Significance of SWIFT:
- Messages sent by SWIFT’s customers are authenticated using its specialised security and identification technology.
- Encryption is added as the messages leave the customer environment and enter the SWIFT Environment.
- Messages remain in the protected SWIFT environment, subject to all its confidentiality and integrity commitments, throughout the transmission process while they are transmitted to the operating centres (OPCs) where they are processed — until they are safely delivered to the receiver.