Payments – Gaurav Tiwari's Blog

Are You Also Seeing an Spike in Fraudulent Messages?

In light of so many scam messages riding on re-KYC, PAN update etc to dupe the customer, here is a lesson I learned while working for HDFC Bank.

I was responsible for ensuring migration of all the cards from CBoP systems to HDFC Bank systems.

After careful consideration I prepared 3 possible strategies and presented to senior management to get their approval on one of them to execute the migration.

The meeting was attended by Group Head of IT, Operations and Business teams along with representatives from both banks.

We all pushed by re-carding. It would have certainly meant significantly more efforts for operations team but they were supportive of me in pushing for this strategy.

I managed to convince almost everyone present except for one person.

While this would have meant the best outcome for the business team, Group Head Business vetoed and rejected re-carding off all CBoP customers with HDFC Bank branded new cards.

He gave a reason that stayed with me forever and I want most people making rules should know this.

He said, “whenever we do activities like this in bulk, it’s an opportunity for fraudsters.”

When customers are expecting this drive from bank side, it gets easier for fraudsters to convince customers of their frauds using this very public drive by bank/authorities.

Update PAN, Link Aadhaar, periodic re-KYC are just few examples of such public drives which make customers vulnerable to frauds. Authorities should always move with caution when proposing anything like this.

Before above conversation I was also convinced of my strategy. In fact I managed to convince everyone else and they actively supported me during the meeting but for one person.

After that I was convinced that I was wrong. We quietly chose the next best option and went ahead. Everything went smoothly.

You learn these things only through practical experiences. No classroom can prepare you for this.

Making UPI Safer

I recently came across NPCI PayAuth Challenge, seeking proposals to improve UPI authentication process to enhance user experience and improved security. I thought this is a good reason to write a new blogpost. I have been a big advocate of risk based authentication and believe that it clearly has the potential significantly improve the authentication process without compromising the security. In fact there is a possibility of even improving security by removing blanket authentication protocol for all transactions.

UPI as a transaction method requires you to register your mobile device as a trusted device after authentication from your bank before you are allowed to transact. Smartphones are capable of capturing a lot of data points at the background. These data points combined with user information and past behaviour data available with your PSP (and/or Bank) can be used to arrive at indicators/score to assess the risk associated with any particular transaction. Based on the risk scope UPI app can trigger authentication protocol. Low risk transactions can be processed without additional authentication while, moderate risk transactions can be approved with simple authentication and high risk transactions can ask for stricter authentication protocols (could be an IVR based referral even if the risk is high).

The idea behind this thought is that your PSP has assess to more behavioral data than your merchant or bank; this behavioral data if used wisely can be an effective tool to offer a seamless transaction authentication experience without compromising on security. PSPs can create a user profile around behavioral data based on things like, where, when, what, how etc. of a transactions. Any deviation from this profile can be triggered for additional authentication.

Nowadays we even have technologies available to create a behavioral biometric profile of a user based on how he normally interacts with his device. This behavioral biometric can be used a first level of authentication (your mobile device is already mapped, which serves as one level of authentication anyway in every transaction) to process the transaction without any Password or PIN. In case of enhanced risk, Password/PIN can be triggered to ensure triple factor of authentication in this case.

1. What you have? your mobile device.

2. Who you are? your behavioral biometric.

3. What you know? Password/PIN

One warning though, do not ever use a SMS OTP based authentication for transaction performed from a mobile device. An OTP is falsely attributed as “What you know?” factor, while it is actually a repeat of “What you have?” An SMS OTP is validating the possession of the mobile device, which is redundant if transaction is performed from pre-verified and tagged mobile device.

Let me illustrate with few examples.

1. Let’s assume a particular customer pays electricity bill to same electricity company every month, in the range of 2000-5000 Rs. How the step-up authentication would work in following scenario?

a. Customer trying to pay bill of 4000 Rs to same electricity company. – Transaction can be approved without additional PIN

b. Customer trying to pay bill of 6000 Rs to same electricity company. – Customer will have to authenticate using PIN

c. Customer trying to pay bill of 3000 Rs to different electricity company. – Transaction will require PIN

2. A customer living in Mumbai regularly transacts at shops in his region with transaction amount ranging between 50 Rs to 5000 Rs depending on merchant category.

a. A transaction with-in the location range on a merchant category-amount combination with-in typical behavior range will be approved without PIN

b. Transactions outside the location range or a different merchant category or value higher than typical behavior range will require PIN.

With machine learning we can create self learning algorithms to cater to more complex scenarios and let the algorithm decide when to step-up the authentication. With more usage, the algorithms will keep on improving making it more effective with time.

PS: I know some start-ups who are working on behavioral biometric and will be happy to do a POC.

PS 2: Happy to brainstorm with anyone whoever is interested, only condition is one will have to adjust to my availability

Supporting Offline Transactions

In a recent communication RBI has pointed out the need for supporting digital transactions in offline mode in order to overcome the handicap of “lack of stable connectivity” as a hindrance to digital adoption. I thought it is a good time to talk about offline authorization, when it comes to processing payment transactions.

Some definitions first:

Authentication: Every payment transaction goes through two steps, authentication and authorization. Authentication is the step that validated the card user. Historically for transactions done using card plastic, this step was performed by taking signature of the customer on the merchant copy of the transaction slip. Then in order to ensure better security, RBI mandated the use of PIN inputted at the encrypted PIN-pad of the point of sale (POS) terminal.

For transactions performed without the plastic, i.e. used on a website, mobile app etc. this step is taken care of by asking the user to input a transaction password or OTP on the authentication page.

Authorization: Authorization is the step that validates the availability of funds. It is this step that is responsible for posting the transaction in your account.

Settlement: Settlement is the step that is responsible for movement of funds from Issuer Bank to Acquirer Bank. As part of this step the merchant claims the money from the acquirer bank and acquirer bank sends this claim to Visa/MasterCard/RuPay, which they then share with respective issuers for processing.

In online transaction scenario authentication and authorization are performed in real time, while the settlement is an offline step, that happens by exchanging the transaction data through the network and does not depend on connectivity at merchant location.

Offline Transaction: When a transaction is processed without connecting to issuer bank’s system in real time. This means the debit in your account will not appear immediately at the time of transaction.

There are two possible ways they will appear in your account, first is at the time of processing settlement, the issuer bank as part of their reconciliation process identify all the transactions where authorization was not performed online, but a settlement was received and post these transactions in customer’s account after reconciliation.

Second possibility is by syncing the offline transactions stored at the card/app next time the card interacts with another POS terminal that has connectivity or app finds the network connectivity. Don’t worry, will try to explain it in more details below.

This offline method of processing payment transactions has been in use in many countries but not in India. There are two primary reasons we did not see such transactions in India, (Transit cards and FasTag are two cases, where India does use offline method). First is low risk appetite. These transactions are riskier and there is possibility of more disputes and even possibility of loss to banks. Second is India is primarily a market driven by savings account and not credit cards. In savings accounts banks pay interest that means if a transaction is processed offline and is posted at a gap of few days to customer’s account (traditionally the gap between authorizations and settlement could be few days in many cases) the bank would in effect be paying interest to customer on money that she has already spent.

Floor Limit: Many countries have this concept called floor limit. What a floor limit means is at certain merchant categories payment transaction can be processed without online authorization provided transaction amount is below a certain amount. This amount in card terminology is referred as floor limit. So far floor limit in India has been Zero. Now from what I understand RBI is planning to make this floor limit as 200 Rs. That would mean any transaction below 200 Rs, processed at specific merchant categories will not require authorization from issuer bank. This transaction will be approved and stored at the terminal level and will be sent to acquirer at the time of settlement.

In this case no authentication or authorization is performed, just the details of the card are captured so that the claim can be prepared for settlement.

Now imagine if this was done few months back, would we have even needed FasTag. One of the very popular use case for this floor limit globally is toll payment.

EMV Cards: I am not sure how many of you know this but besides EMV being more secure, one of the reasons EMV was introduced was because of its capability to process transactions in offline mode, thus avoiding the need of sending every transaction through network and save on cost of communication. For countries where telecom cost is high, this could mean significant savings.

EMV protocol supports offline mode of transaction processing by provisioning for offline PIN, something that can be validated at card itself, thus taking care of the authentication step. There are various other parameters like last known balance (i.e. the balance at the time of last online transaction), cap on number of transaction (total number of transaction that can be approved at card chip level before it will force the transaction to go online. For example if this parameter is set up as 4, the chip will force every 5th transaction to be online. This 5th transaction will carry with it all the other past offline transactions thus syncing the issuer systems in the process.) and amount (cumulative amount up to which the chip on the card can process transaction in offline mode. Similar to the cap on number of transaction the moment this threshold is hit the chip forces the transaction to be processed online). From what I have read, it looks like RBI is proposing to set this amount limit at 2,000 Rs.

Most of the systems at banks these days are capable of the methods described above and should be able to implement without making much changes, thus can be rolled out fast.

Similar principles can be used in order to build the capability for other modes, which do not follow card protocol. In fact in case of modes like UPI, where a mobile device is involved this can be done in much better way considering unlike card a mobile device in capable of connecting to the issuer directly as soon as it finds network.

How Does FASTag Work?

FASTag is part of NETC (National Electronic Toll Collection) program by NPCI designed to provide an interoperable method of toll collection across the country irrespective of the acquirer, simple meaning that your FASTag device issued by any issuer will work on any toll plaza across the country irrespective of its acquirer. That is the benefit you get when working with NPCI.

Couple of days back a friend working in transit payments called me to understand how FASTag works. That call gave me impression to write this post. Here I will be explaining the transaction flow of a FASTag transaction in simple terms:

What is FASTag?

FASTag is a RFID tag that stores static information like TAG ID, which can be read by the receivers installed at toll plazas.

How it is issued?

FASTag can be issued by any NETC member banks and it is linked to either your Current or Savings account maintained with the bank or a prepaid account created by the bank for this specific purpose. My bank gave me a prepaid account with separate credentials for inquiry and other financial transactions. In my opinion it will be wise for fleet companies to link FASTag for their vehicles to current account maintained by the company.

At the time of issuance a TAG ID is created, which is then linked to a CASA Account or Prepaid Account, depending on the implementation at your bank and your vehicle details like vehicle type (car, truck etc.) and category (personal, commercial etc.). TAG ID along with Vehicle details and Bank ID are then added in NETC mapper maintained by NPCI. As soon as your details are updated in NETC mapper, your FASTag is ready to use.

How it works?

NETC Transaction Flow (Image Source: NPCI)

Step 1: As soon as RFID tag affixed to the windshield of your vehicle is in range of the acceptance terminal installed at toll gate, terminal read the TAG ID and Vehicle Details and send them to acquiring bank

Step 2: Acquiring bank sends the details received from the terminal to NETC mapper,

Step 3: NETC Mapper validates the details collected from the TAG and responds with TAG Status. If TAG Status is active, it proceeds to next step else driver needs to pay cash. Other possibilities could be TAG is not registered yet (new TAG), TAG is blacklisted etc.

Step 4: After successful validation of TAG details and status, Acquirer system calculates the toll amount to be collected and sends to NETC Mapper.

Step 5: NETC System sends the debit request to issuing bank, based on the issuer bank ID maintained in the Mapper.

Step 6: Issuer system processes the debit into customer’s account linked to FASTag and sends response back to NETC system. In case no response is received with-in the defined time-out period it is assumed to be approved automatically.

Step 7: NETC System sends a notification to the acquirer system

Step 8: Acquirer system sends notification to respective toll plaza system

This transaction is performed in offline mode with systems syncing every 10 minutes. This means that by the time Step 8 happens your car is already far away from the toll-plaza. Once the TAG ID is validated and its status is found to be active, it is assumed that there is enough balance maintained at the bank’s end to settle the transaction, which happens at every settlement cycle and facilitated by NPCI through a system called EGCS (ETC Global Clearing and Settlement).

Settlement flow for FASTag transactions. (Image Source: NPCI)

NPCI basically collects the money from issuer banks and distributes it among acquirer banks as per the transactions processed during the settlement cycle. Acquirer bank then settles the funds with respective toll plazas.

What happens if your account does not have money?

Since the value of toll is usually small and syncing cycle is ten minutes, the exposure due to lack of funds in account is very limited. Having said that banks have a provision of keeping a security deposit for safeguarding themselves in any such possibility. In case your account does not have necessary funds to pay for the toll, same is deducted from your security and your FASTag is blacklisted and updated in NETC mapper to stop further transactions on that TAG till balance is maintained again.

My bank has taken 500 Rs as security deposit. The assumption is that for a private vehicle to pass through so many toll plazas with-in 10 minutes is practically very remote. I am assuming for heavy/commercial vehicles this security deposit would be higher. In case of fleet companies having multiple tags linked to same current account there might be a special arrangement negotiated with the issuer bank.

How to reload a FASTag account?

In case it is linked to your savings or current account, there is no question of separately reloading the account. While my bank doesn’t offer me this option, I am assuming, whichever banks would be offering this option must be keeping some cap on the amount from safeguarding perspective.

In case of prepaid account set-up like my bank, I have been given multiple options to reload. Your bank may even offer an auto-reload option where, if your balance goes below a particular threshold bank can initiate a reload by debiting your linked account or card that you may have provided while setting up the FASTag account.

This is the simplest explanation I could come up with for FASTag transaction flow that is easy to understand by most and also explains how it can be achieved at the speed of traffic i.e. your car practically doesn’t need to stop at the plaza for deducting the toll. This is unlike the regular transit card solutions where balance is usually maintained at the chip inside the card and offline balance is updated at the time of transaction.

Even more thoughts on MDR debate

In my last post I had touched upon the entire authorization piece for card transactions and how it makes sense to have MDR for Credit Card transactions however it feels unreasonable when it come to Debit Card transactions. Today I will explain the settlement aspect of transaction and try to make sense of MDR charges based on settlement flow.

How settlement for a card transaction works?

After transaction is completed merchant claims money from the acquiring bank. Acquiring bank further sends a file to Interchange and Interchange gets the money from Issuer Bank. This entire cycle traditionally used to take days.

Acquiring bank is making a guarantee to the merchant and based on that guarantee, they process the transaction. Interchange is giving the guarantee to acquirers. Meaning in the event of an issuers inability to pay for a transaction done by its customer the interchange will ensure that the acquirer gets paid for the money they have paid to the merchant.

Above risk is high if you assume settlement cycle spread across many days. However in today’s fast paced world the settlement cycle is shrinking. We are practically settling the transaction with-in T+1 days. There are continuous attempts to shrink this cycle to make it even near real time. If that happens the risk by acquirers and interchange is going to be practically zero.

Many debit cards in the market even follow a single message settlement protocol similar to ATM transactions. In this case there is no need for merchant to process any batch settlement. The settlement is processed automatically by default.

This risk taken by acquirers and interchange on top of supporting the ecosystem with their technology and operations is additional justification for them getting a share of the transaction fee, however this still beats me, why the fee should be paid by the merchant and not by the issuer.

The merchant is the first one to go out of pocket (he has sold the goods without money in his/her account) hence contributes to zero risk in this entire ecosystem. Customer is using his debit card meaning he/she is using the money that he/she has parked in the his/her account already, hence not contributing to any risk. At the time of transaction the money is debited from customer’s account and parked in a payable account by the issuer bank. It is this account that is used to settle money with the interchange.

If a issuer bank has managed to get into a situation somehow (recent Yes Bank situation) that they are not able to settle with the interchange it is definitely not because of the customer and/or the merchant, hence in all fairness it is them who should fund the entire ecosystem from their income through deposits and not fleece the merchants.

If you want merchant to pay MDR, issue credit cards and give enough incentives to your customers to use them. If customer prefers to use his/her debit card instead, it is ideally his/her bank’s responsibility to offer necessary ecosystem to access his/her funds. Always remember the issuer banks are already making profits by investing this money parked by customers in their CASA.

Four years back RBI suggested some reforms in this consultation paper however no action has happened in that direction. What I am suggesting is not exactly the same but fundamentally both are using the base analogy that the benefits are currently unfairly tilted in favor of issuer banks and it is these issuer banks who should bear the most of the burden instead of expecting other players in the ecosystem to fund for the infrastructure needed for its customers to access funds parked in their accounts in these banks.

Recent growth in this ecosystem was fueled by VC/PE money, which may not be available in same proportion given the current global slowdown caused primarily by the Coronavirus pandemic. This means some key players will find it extremely difficult to survive and it will not be good for the overall digital payment ecosystem. It is in the interest of issuer banks to save this ecosystem by taking ownership of the costs involved. If that doesn’t happen, only players surviving will be the ones with deep pockets not the ones with better innovation. This will eventually kill the innovation in this space and steer entrepreneurs away from attempting new/innovative solutions in this space.

More Thoughts on MDR Debate

So much chatter going on in Indian market around MDR, short for Merchant Discount Rate, thanks to NPCI making MDR zero for RuPay debit card transaction based on instructions from Finance Ministry. I had touched upon this topic once before here. However now coronavirus pandemic putting extra pressure on most of the businesses including payment facilitators, this topic is again making rounds. I felt like I should put together one post explaining my views in other post where I have supported the move of zero MDR.

First thing let’s talk about what is MDR and why it has been there as a key source of revenue for payment providers. MDR is the money that is paid by the merchant to the payment ecosystem used in facilitating the transaction. All the parties involved in the value chain i.e. acquirer, interchange and issuer get their share from this MDR including the third party technology or operations service providers used by these parties. MDR is typically a small percentage of transaction value, somewhere between 0.8 percent to 3 percent. Essentially what it means is that when you pay a merchant 100 Rs using your American Express credit card, the merchant actually gets only 97 Rs, while the 3 Rs are used to pay everyone involved in facilitating this exchange.

Now why would a merchant agree to take a cut in his/her income to facilitate this after-all it’s the merchant who drives the mode of transaction and not other way round. How often have you refused to deal with a merchant because he did not accept your credit card? You find a way to pay that merchant accepts and move on with your purchase. Then what is the answer? In a credit card world card company is facilitating the purchase by offering an instant credit to the customer thus taking a risk on the transaction, this risk taken by the issuer enables the purchase to go through, which may not have happened in case the credit was not issued at the time of transaction. Now here is something for the merchant to gain, he is gaining a sale, which may not have happened otherwise. That is the reason merchant doesn’t mind paying that MDR. Now issuer alone cannot support this massive ecosystem, so parts of this MDR is distributed among other participants in the ecosystem.

If the MDR was for supporting the technology and operational cost for running the ecosystem, it would have been a flat fee and not a percentage of the transaction amount, because cost of processing a transaction remains more or less the same irrespective of the transaction amount. So primary reason a merchant agrees to pay an MDR is because issuer is taking a risk on the transaction by issuing an instant credit in order to facilitate the purchase. Bigger the amount, bigger the risk for the issuer.

Then industry launched debit cards in order for customers to access the funds parked in their savings and current accounts. Instead of reinventing the wheel, they decided to ride on the same infrastructure set-up for credit cards to facilitate debit card transactions as well but then they got too lazy and even copied the same MDR based business model. In case of debit cards customer has already parked funds in banks and banks are making more money from that money and it is responsibility of banks to facilitate access of funds in his/her bank account to its customer. Banks do not want customers to line up in the branches because that is the most expensive mode of transaction for banks, in order to save that cost banks have set up digital infrastructure to provide easy access to customers, this also includes POS/Payment Gateway infrastructure.

I am of the view that MDR model is fine for credit card universe however it does not make any logical sense for debit card transactions and issuer banks should bear the cost of these transactions instead of passing that cost to merchants or customers in anyway. Issuer banks should pay interchange and acquirers on fixed fees basis, then acquirers should compensate their technology and operations partners from their share. Interchanges as the bodies at the center of all this should facilitate working of a reasonable compensation mechanism for sustainable ecosystem growth.

Since the industry had been running on this illogical model for far too long everyone had gotten used to it; but zero MDR move by Government should work as a catalyst to drive this change and implement a more logical and sustainable business model, which is not designed to unreasonably favor the banks. Banks should not be allowed to only benefit from this entire ecosystem, while other partners share the entire burden of cost. I hope NPCI leads the way here with support from RBI and Finance Ministry to arrive at a agreeable solution that doesn’t ruin the payment facilitators and force them out of business. If that happens customer will be the biggest loser.

PS: This piece was originally published as my opinion piece on IBS Intelligence blog.

Google Debit Card

Recently I came across news stories covering Google’s plan to launch a Debit Card. It all started with this TechCrunch article comparing this move with Apple Card launch. First of all, to me that is not a fair comparison to begin with because Credit and Debit card are two fundamentally different products at their core. If you keenly analyse the brand positioning of Apple vs Android, you would realize that these offerings are very much in-sync with that. This also reflects the markets where each of them are dominant players. While Apple’s dominance is in markets where credit is primary mode of transaction, however Android is leader in markets with savings account as primary source of funds for day today expenses. All those jokes about one needing credit to buy an iPhone are based on some truth.

As the TechCrunch article also pointed out, it is not Google’s first attempt at launching a card, they tried it when they launched Google Wallet in 2012. (I keenly followed that project, because I was in process of building my own wallet before Google announced their pilot. This is story for another time though.) While there were many aspects of Google Wallet that I found fascinating, I was skeptical about the debit card bit because of the entire on-boarding experience. I had seen journey of multiple debit card variants physical, virtual, mobile launched by HDFC Bank to make that prediction.

Now however the times have changed. First of all, now Google has experienced massive success in India under UPI product, which inherently accesses the funds from CASA accounts only. This must have given massive confidence boost to Google Pay team to make another attempt at launching an instrument accessing funds from CASA accounts. Since UPI is as of now an India specific phenomenon, Google is trying to rely on Debit Card variant one more time, now riding on the newfound confidence. What will be the on-boarding experience is not yet known, but if they can use the learning from earlier experience, they might be able to do it better. We managed to issue a very efficient mobile variant of debit card in 2006-07, as part of m-Chek project I did for HDFC Bank in partnership with then m-Chek and Airtel. It was for not so smart phones popular back then, now the world has moved much ahead in technology adoption.

Why Google would want to do this? My answer to this question is still the same as it was in 2013. Google’s primary source of revenue is ads. Currently Google can very efficiently track the efficiency of their ads right up to the point of click, however it is not so efficient when it comes to tracking the last mile of purchase. Being able to know the effectiveness of their ads right up to the point of purchase is equivalent of digital gold for Google, a company that has built the biggest empire on user data.

This data will be the key to unlocking an effective way for selling Financial Products like Insurance, Investment Products etc, which are essentially push products and no digital company has so far been able to crack the code for selling such push products (I was planning to go on this journey but then fate had other plans for me). If Google can crack this piece of the puzzle with access to this additional data, it will completely revolutionize the way products are sold digitally and I am not talking about Financial products only here.

In addition to above it would be very easy for Google to push transactions happening with-in their ecosystem on these cards. This is what the partnering banks gain, an easy distribution channel and almost certain activation, with massive transaction value flowing through these cards.

In summary, if done right, I believe it is going to be a game-changing move completely different from Apple Pay’s journey. This not only has the potential to impact Fintech world in a big way but also how entire digital commerce is done today.

PS: This also has the potential to make Google first truly effective neo-bank for retail customers, however I am not sure if Google would have those aspirations.

Transit Payments

Coronavirus (COVID19) has made us all conscious about avoiding unnecessary human contact to protect oneself from getting infected. This made many people think about how cash can be one of the careers. I am not familiar with the biology of the virus and how exactly this transmission would work. However if people are worried about cash then exchanging cards during transaction or touching POS machine to input PIN can also be a problem. That means in the days of COVID-19 safest mode of payments (talking from health perspective here) would be contactless payments like QR codes, NFC, RFID, Tone etc. Transit payments is one of the most popular use case of contactless payments around, which has been even more mainstream since the push for Fastag for toll payments by Indian Government.

During my banking days, I got the chance to lead the solution for Jaipur Metro (JMRC), which was being managed by DMRC. So essentially I got to study how Delhi Metro payments work and also design the solution for JMRC using the learning from Delhi project. In this post I would like to explain some of the key factors to be kept in mind while designing such a solution.

Transit payments are a different category for a very simple reason because of its need to be exceptionally fast, much faster than any other payment method we use. If the transaction is not processed with-in a fraction of second end-to-end we can see endless queue of angry customers forming, be it payments at toll-booth or entry and exit points of metro stations or entry and exit points of your city bus. We do not have the luxury to take 10-15 seconds to process the transaction, when it comes to this particular use case. That takes online authentication out of the picture. Offline authentication is the method of authentication where transaction is authorized locally by the instrument itself without traveling to issuer host system over the network.

The technology commonly used for this type of transaction processing is RFID (Radio Frequency Identification). When you are issued a card or a sticker or any other form factor, it typically contains an RFID chip, which communicates with the receiver installed at the gates of transit system to read the balances and post transactions. The instrument used for this purpose is typically a prepaid card, where the balance is updated at the CHIP locally, hence eliminating the need to communicate with the server every time transaction needs to be processed.

There are combo version of these cards also popular, which are nothing but debit/credit cards with either an additional RFID Chip embedded inside the plastic dedicated for transit payments prepaid card or have a separate dedicated block in the EMV chip for this purpose. Essentially they are for all practical purpose two cards linked to a single plastic.

How a typical transaction works?

Transaction at single interaction point like toll-gate is very simple because there is a fixed amount to be deducted every time you pass through the gate. The receiver installed the gate access the balance on your Fastag and update the balance by deducting the fixed amount.

Transactions with two gates i.e. interactions at entry and exit points like metro gates or city bus are slightly more complex. In this case at the time of entry the receiver installed at the gate checks the balance and updates the entry point on the CHIP. At the point of exit when you flash your card the receiver at the exit gate calculates the fare based on the entry point and deducts the amount from the prepaid card updating the balance accordingly.

How the card is reloaded?

Reloading of these cards works very similar to any other prepaid wallet or prepaid SIM, where you go to partner bank’s point of interaction Branch, ATM, NetBanking, Mobile Banking etc (depends on the partner bank) provide your unique ID (ID tagged to the RFID Chip) and make the payment.

The bank then communicates this to the transit partner and this reload transaction is updated in their system. The moment your card comes in contact with the sensors at transit partner the balance is updated in the CHIP. You can alternatively access special devices installed by the transit partner for specific purpose of load/reload of transit card. This can even be done over the counter by transit partner.

In JMRC project we even had provision of stand-in instruction wherein every time sensors at transit partners read the balance in your transit card go below a pre-set threshold the bank will get a file from the transit partner with all such card IDs, banking partner will then debit their respective linked accounts by a predefined amount and send the file back to transit partner to update the balances in their systems.

NPCI has developed specifications under Rupay Contactless Product umbrella, which is now the basis for NCMC (National Common Mobility Card), which is expected to be the dominant mode for transit payments in near future.

Co-branded Cards: Can It Go Beyond Branding

I had come across multiple news items regarding various co-branded cards like RBL Bank launching co-branded card with Zomato and HDFC Bank launching co-branded cards with Indigo Airlines. These stories prompted me into writing down my thoughts on this very popular product category among payment cards.

During my days in Banks I had worked on a co-branded card program in partnership with Jet Privilege. Apart from printing the Jet Privilege logo and customer’s JP number on the card the partnership also brought a common/shared reward program. From customer’s perspective customers could earn their credit card reward points in the form of JP miles and also get other promotional benefits that Jet Privilege was offering to its members. It has been years since and so far the fundamentals of co-branding remains the same.

In today’s day and age when mobile phone is increasingly becoming the preferred payment instrument instead of card plastic, specially with brands like Zomato and Indigo Airlines, I would have expected co-branded cards to offer benefits beyond shared promotions and rewards. Call me a demanding customer but if the common goal of co-branding exercise for both the brands is customer acquisition and retention, wouldn’t offering superior transaction experience across shared brand will enhance the offering even further. While banks are still in denial about UX being a key part of customer acquisition and retention strategy, brands like Zomato must know this very well.

One of the examples of how co-branding can go beyond shared rewards and also offer superior transaction experience between shared brands (specially for mobile phone universe) is single click transaction with partner brand. As part of co-branding exercise both entities exchange the customer identities at their respective ends, why not shared authentication.

When I implemented 3 D Secure, which is the back bone of online 2 factor authentication process for Visa (branded as VbV – Verified by Visa), MasterCard (branded as MasterCard Secure Code) and Diners cards, there was a model called Issuer Trusted Party of ITP, which allowed issuers to enable trusted third parties to perform 2nd factor of authentication during online transactions.

If I take Zomato and RBL Bank as sample case here, RBL can register Zomato as trusted third party and allow Zomato’s customer authentication as 2nd Factor Authentication by-passing Bank’s OTP during the transaction. This would mean that RBL Bank’s Zomato co-branded card holders will not only get the shared rewards and promotions, they will also have better transaction experience than any other card holders, thus making the case even stronger for customers to go for this card.

I am not sure how strong Zomato’s customer authentication mechanism is to be used at 2nd factor authentication for payment transaction but in this digital age they should have a strong authentication, if not they must work on it then.

डिजिटल भुगतान: कार्ड पेमेंट (पार्ट-४): धोखाधड़ी की रोकथाम

यह कार्ड भुगतान पर मेरी श्रृंखला का अंतिम भाग है और इस पोस्ट में मैं कार्ड उपभोक्ताओं को लक्षित कुछ आम धोखाधड़ी के तरीकों को कवर करने की कोशिश करूँगा। हम यह भी देखेंगे कि आप इन सबसे अपनी रक्षा कैसे कर सकते हैं।

स्किमिंग: लेनदेन के समय आपके कार्ड की जानकारी चुराने और फिर उस जानकारी का दुरुपयोग करने की प्रक्रिया ‘स्किमिंग’ है। स्किमिंग के द्वारा आपके कार्ड पर धोखे से लेनदेन की जाती है। इसमें जब भी कार्ड को पीओएस या एटीएम डिवाइस पर स्वाइप किया जाता है तो जालसाज स्वाइप के समय कार्ड की जानकारी चुराने के लिए एक बाहरी कार्ड रीडर को अटैच करता है।

इस तरह की धोखाधड़ी को रोकने के लिए सबसे प्रभावी उपाय चिप (ईएमवी) कार्ड का प्रयोग है। आरबीआई ने सभी कार्ड जारीकर्ताओं को यह सुनिश्चित करना अनिवार्य कर दिया है कि जारी किए गए सभी डेबिट और क्रेडिट कार्ड चिप कार्ड हों। एटीएम मशीनें अपने कार्ड रीडर्स को ऐसे डिजाइन कर रही हैं ताकि किसी भी अतिरिक्त बाहरी घटक को अटैच करना मुश्किल हो सके। पर अपने-आप को इससे बचाने के लिए कुछ सावधानियाँ इस प्रकार हैं:

१. सुनिश्चित करें कि कार्ड हर समय आपकी दृष्टि में रहे और जिस डिवाइस पर कार्ड स्वाइप किया जा रहा है वह आपको स्पष्ट रूप से दिखाई देता रहे। और इसमें कोई बाहरी घटक डिवाइस से जुड़ा हुआ नहीं रहे।

२. एटीएम का उपयोग करते समय सुनिश्चित करें कि एटीएम के कार्ड रीडर से कोई बाहरी घटक जुड़ा हुआ नहीं है (कई एटीएम जो अभी भी चुंबकीय रीडर का उपयोग करते हैं, कार्ड रीडर में कार्ड प्रविष्टि को बाधित करने के लिए “जिटर ” का उपयोग करते हैं; जो यह सुनिश्चित करता है कि कार्ड डेटा बाहरी डिवाइस द्वारा कैप्चर नहीं किया जा रहा है)। कार्ड रीडर पर किसी बाहरी घटक संलग्न होने की पहचान करने का एक तरीका कार्ड रीडर से प्रकाश के “ब्लिंक” होने को सुनिश्चित करना भी है। यदि आप स्पष्ट रूप से कार्ड रीडर पर प्रकाश नहीं देख सकते है तो उस एटीएम का उपयोग करने से बचें।

इस प्रकार की धोखाधड़ी लोकप्रिय पर्यटन स्थलों में विशेष रूप से प्रचलित है। कारण यह है कि कार्ड एक पर्यटक का है जो अपनी अपने घर लौटकर बाहर में की गयी कार्ड गतिविधियोँ की समुचित जाँच और पूछताछ नहीं कर पाता। यात्रा के समय आपको कार्ड को लेकर ज्यादा सचेत रहना चाहिए। अपने हाल के ऑस्ट्रेलिया दौरे पर मैंने देखा कि वहाँ के दुकानदार आपको खुद से कार्ड स्वाइप करने के लिए प्रेरित करते हैं, जो एक सुरक्षित तरीका है।

फ़िशिंग: फ़िशिंग वही है जो इसका शाब्दिक अर्थ लगता है (मछली पकड़ना)। इसमें जालसाज, लोगों को अपनी संवेदनशील जानकारी प्रकट करने के लिए लक्षित करता है। फ़िशिंग के बारे में जानने का एक और मनोरंजक तरीका है, नेटफ्लिक्स “जामतारा” वेब-सीरीज जो एक दूरदराज शहर के युवाओं के एक दल द्वारा चलाए जा रहे टेली-कॉलिंग फिशिंग रैकेट पर आधारित है।

विकिपीडिया परिभाषा के अनुसार, “इलेक्ट्रॉनिक संचार में फ़िशिंग एक छुपे हुए जालसाज द्वारा उपभोक्ता का नाम, पासवर्ड और क्रेडिट कार्ड विवरण के रूप में संवेदनशील जानकारी प्राप्त करने के लिए धोखाधड़ी का प्रयास है।”

यदि आपको अपने जारीकर्ता या किसी अन्य इकाई से कॉल, एसएमएस या ई-मेल प्राप्त होता है जिसमें आपसे कार्ड नंबर, पिन, सीवीवी, ओटीपी, नेट बैंकिंग आईडी और पासवर्ड आदि जैसी संवेदनशील जानकारी साझा करने का अनुरोध किया जाता है तो इस तरह की धोखाधड़ी से खुद को बचाने का एकमात्र तरीका यह है कि किसी भी माध्यम पर अपनी संवेदनशील जानकारी साझा न करें। आपका बैंक कॉल, एसएमएस या ई-मेल पर ये विवरण कभी नहीं पूछेगा।

वेबसाइट स्पूफिंग: इसमें धोखेबाज एक वेबसाइट बनाएंगे जो किसी अन्य विश्वसनीय इकाई की वेबसाइट की तरह दिखती हो; यहां तक कि यूआरएल भी समान दिखता हो (सामान्यतः इसमें किसी एक करैक्टर को बदल दिया गया रहता है)। इसका बचने का एक सरल तरीका है कि आप ई-मेल या एसएमएस पर प्राप्त लिंक पर क्लिक करने के बजाय यूआरएल को स्वयं टाइप करें।

वेबसाइटों द्वारा उपभोक्ताओं को सही पेज पर पहुँचाने के लिए कुछ चेक और नियंत्रण दिए जाते हैं। उदाहरण के लिए, कुछ वेबसाइटों में एक छवि या संदेश प्रदर्शित होता है जिसमें आपको संवेदनशील जानकारी इनपुट करनी होती है। एचडीएफसी बैंक नेटबैंकिंग एक तस्वीर और आपके द्वारा चयनित संदेश अपने लॉग-इन पृष्ठ पर प्रदर्शित करता है ताकि यह सुनिश्चित किया जा सके कि आप अपनी जानकारी प्रामाणिक बैंक के पेज पर डाल रहे हैं न कि किसी अन्य स्पूफ्ड वेबसाइट पर।

सोशल इंजीनियरिंग: धोखाधड़ी का यह तरीका किसी उद्देश्य के लिए उपयोग की जा सकने वाली गोपनीय या व्यक्तिगत जानकारी को प्राप्त करने के लिए जालसाज द्वारा प्रयोग में लाया जाता है। ऊपर बताई गई ‘फिशिंग’ एक प्रकार की सोशल इंजीनियरिंग है। इस संदर्भ में सोशल इंजीनियरिंग के कुछ अन्य तरीके हैं ‘विशिंग’ – जहां धोखेबाज किसी कंपनी के ग्राहकों से संवेदनशील जानकारी प्राप्त करने के लिए उसके आईवीआर (इंटरएक्टिव वॉयस रिस्पांस) की नकल करेंगे; या फिर ‘बेटिंग’ – जिसमे जालसाज आपको ई-मेल या एसएमएस पर एक लिंक भेजेगा जिससे आप कुछ इनाम या कुछ नुकसान के खतरे के वादे के कारण संक्रमित लिंक पर क्लिक कर बैठेंगे।

वास्तविक दुनिया में नाइजीरिया या सूडान का कोई राजकुमार आपके साथ अपनी संपत्ति साझा करने के लिए मरा नहीं जा रहा; न तो आपने किसी कोका-कोला या रीडर्स-डाइजेस्ट की लॉटरी जीती है। आरबीआई या आयकर विभाग भी आपके खाते में पैसे नहीं डाल रहे, और न ही पीएम नरेंद्र मोदी आपको स्विस बैंक से वापस लाये पंद्रह लाख रुपये देना चाहते हैं। इस लिए अपना बैंक अकाउंट या कोई अन्य व्यक्तिगत जानकारी किसी को न भेजें। रसोई गैस की सब्सिडी पाने के लिए भी आपको बस अपना आधार कार्ड अपने बैंक अकाउंट से लिंक करना होता है, और कुछ नहीं।

मनी-म्यूल: एक मनी-म्यूल जिसे कई बार ‘समर्फर’ भी कहा जाता है, वह व्यक्ति है जो धोखेबाजों को अवैध रूप से पैसे हस्तांतरण में मदद करता है। यदि आपको कोई ऐसी कहानी सुनाता है कि उसे बहुत सा धन ट्रांसफर करना है और आपके अकाउंट को कुछ दिनों के लिए पैसे “पार्क करने” और फिर आगे ट्रांसफर करने का जरिया बनाना चाहता है तो समझ जाएँ कि आपको एक बड़े फ्रॉड में फंसाने की तैयारी है।

जब पैसा डिजिटल रूप से ट्रांसफर होता है, तो यह एक “ट्रेल” यानि निशान छोड़ देता है और इसका उपयोग जालसाज की पहचान करने और गिरफ्तार करने के लिए किया जा सकता है। इससे बचने के लिए धोखेबाज बड़ी संख्या में विभिन्न खातों के माध्यम से पैसे भेजकर एक विस्तृत निशान बनाते हैं। यदि आप एक मनी-म्यूल के रूप में कार्य करते हैं तो आप धोखाधड़ी में एक सह षड्यंत्रकारी बन जाते है और किसी भी आपराधिक कार्यवाही होगी तो आप उत्तरदाई होंगे। तो थोड़े फायदे के लिए अपराधी बनने से बचें।

अपने मोबाइल फोन की रक्षा करें: इन दिनों डिजिटल लेनदेन के समय आपका मोबाइल फोन बहुत महत्वपूर्ण हो गया है। कई मामलों में आपके मोबाइल डिवाइस का उपयोग प्रमाणीकरण के एक मोड के रूप में प्रयोग किया जाता है। अधिकांश समय आपके मोबाइल फोन पर प्राप्त ओटीपी का उपयोग २-कारक प्रमाणीकरण के रूप में किया जाता है और कई बार वेबसाइटों और मोबाइल ऐप्स आपके कार्ड विवरण को स्टोर करते हैं।

अब आप कल्पना कीजिये कि आपने अपना फोन खो दिया और वह किसी जालसाज को मिल गया। आपका फोन अनलॉक है क्योंकि आपने फोन को पासवर्ड या फिंगरप्रिंट से प्रोटेक्ट नहीं किया है। जालसाज ने देखा कि अपने फोन में आपने अपने टेलीकॉम ऑपरेटर का एप्प रखा है जिसमे आपका कार्ड इन्फॉर्मेशन भी सेव किया हुआ है। अब वह जालसाज आपके कार्ड की जानकारी और आपके फोन पर आने वाले ओटीपी को प्रयोग करके कोई भी ऑनलाइन खरीददारी कर सकता है। इस घटना से आपको सिर्फ कार्ड के पीछे लिखा सीविवि नंबर बचा सकता है, पर यह जानकारी भी आपसे धोखे से ली जा सकती है।

इस मामले में मेरी एकमात्र सलाह है कि १. अपने मोबाइल नंबर को केवल उन ऐप्स/वेबसाइट पर स्टोर करें जिनका आप अक्सर उपयोग करते हैं; २. अपने स्मार्टफोन पर एक्सेस कंट्रोल सेट करें चाहे वह पिन, पैटर्न, फिंगरप्रिंट या फेस आईडी में से कोई भी सुरक्षा हो, ३. अपना फोन खोने न दें और खोने पर अपने कार्ड के साथ अपना फोन नंबर भी ब्लॉक करवा दें।

अंत में एक महत्वपूर्ण सलाह यह है कि अगर आप किसी भी प्रयोजन से अपनी आईडी प्रूफ या के.वाई.सी. की कॉपी दे रहे हों तो उसपर तारीख और प्रयोजन लिख कर हस्ताक्षर करें ताकि आपका वह प्रमाण किसी जालसाज द्वारा आपके बैंक में जमा करके बैंक को कोई निर्देश देने (उदाहरण के लिए पता बदलने, कार्ड के पुनः जारी करने, पिन का पुनः जारी करने, नई चेक बुक आदि) के लिए प्रयोग में नहीं लाया जा सके।

इस लेख का हिंदी अनुवाद मेरे ट्विटर मित्र राहुल तिवारी ने किया है। आप लोग उनको ट्विटर पे @In_Blogger फॉलो कर सकते हैं।

डिजिटल भुगतान: कार्ड पेमेंट (पार्ट-३): सुरक्षा

कार्ड भुगतान पारिस्थितिक तंत्र को उसके पूरे वैल्यू-चेन में शामिल विभिन्न पक्षों की सुरक्षा की दृष्टिकोण से डिज़ाइन किया गया है। मैं अपने “डिजिटल भुगतान” (पेमेंट) सीरीज में इस लेख को इन सुरक्षा उपायों के ऊपर केंद्रित करना चाहूंगा ताकि उपभोक्ता इसकी जानकारी रख सकें। कार्ड भुगतान से सम्बंधित हर इकाई, सिस्टम और प्रक्रिया को भुगतान कार्ड उद्योग (पीसीआई-डीएसएस) द्वारा स्थापित डेटा सुरक्षा मानकों का पालन करना होता है; ताकि सभी संवेदनशील जानकारियाँ किसी भी समय सुरक्षित रह सकें।

~ कार्ड जारीकर्ता द्वारा नियंत्रण ~

कार्ड प्रिंटिंग: कार्ड जारी करने के समय ‘कार्ड प्रिंटिंग फ़ाइल’ बनाई जाती है, जिसे ‘एन्क्रिप्टेड’ प्रारूप में प्रिंटिंग इकाई में ले जाया जाता है। कार्ड प्रिंटिंग पूरी होने के बाद इसे नष्ट कर दिया जाता है। मैं इस तरह की एक प्रिंटिंग इकाई में गया और मैंने उसके सुरक्षा मानकों का स्वतः अनुभव किया है। डेटा सुरक्षा के साथ वे शारीरिक सुरक्षा पर भी सख्त नियंत्रण रखते हैं। वहां आगंतुकों को कई बंद दरवाजों के माध्यम से ले जाया जाता है और उन्हें जेब वाले कपड़े पहनने की भी अनुमति नहीं होती है।

चिप (ई.एम्.वी. कार्ड): पहले कार्ड द्वारा लेनदेन में चुंबकीय पट्टी का उपयोग किया जाता था। चुंबकीय पट्टी के साथ समस्या यह थी कि इसमें संग्रहीत जानकारी स्पष्ट रूप में संग्रहीत की जाती थी और कार्ड रीडर पर कार्ड स्वाइप करके धोखेबाजों द्वारा चोरी की जा सकती थी। कार्ड की जानकारी चुराने की इस प्रक्रिया को “स्कीमिंग” कहा जाता है। इससे उपभोक्ताओं की सुरक्षा हेतु भारतीय रिज़र्व बैंक ने अब ई.एम्.वी यानि चिप वाले कार्ड का प्रयोग अनिवार्य कर दिया है। ई.एम्.वी कार्ड का लाभ यह है कि इसके चिप में संग्रहीत सभी जानकारी एन्क्रिप्टेड रूप में होती है।

पिन प्रिंटिंग: आपके कार्ड का पिन कहीं भी किसी भी सिस्टम में संग्रहीत नहीं है। पिन जारी करने के समय पिन ब्लॉक एक जटिल तर्क और एन्क्रिप्शन का उपयोग करके उत्पन्न होता है और सीधे पिन-प्रिंटर को निर्देशित किया जाता है। पिन को सील रूप में ही मुद्रित किया जाता है, और केवल पिन मेलर को फाड़कर ही देखा जा सकता है। इससे पिन की सूचना उपभोक्ताओं को पूर्णतः सुरक्षित रूप से पहुँचाई जाती है। इस प्रक्रिया में सावधानी का स्तर यह है कि कार्ड और पिन दोनों अलग-अलग स्थानों पर मुद्रित किए जाते हैं (उदाहरण के लिए एच.डी.एफ.सी. बैंक के कार्ड चेन्नई में मुद्रित किए जाते हैं, जबकि पिन प्रिंटिंग आमतौर पर मुंबई में होती है)। ऐसा यह सुनिश्चित करने के लिए किया जाता है कि कार्ड और पिन उपभोक्ता के पास पहुंचने से पहले कभी भी एक साथ नहीं होते हैं। इसके अलावा, कार्ड सिर्फ उपभोक्ता के पते पर ही भेजे जाते हैं। डिलीवरी-मैन आमतौर पर आपको कार्ड किट सौंपने से पहले ‘आईडी प्रूफ’ भी मांगता है।

पिन सत्यापन: लेन-देन के समय पिन को कुंजी पैड (की-पैड) पर एन्क्रिप्ट किया जाता है और एक एन्क्रिप्टेड पिन ब्लॉक उत्पन्न होता है। पिन एन्क्रिप्टेड प्रारूप में प्रमाणीकरण के लिए जारीकर्ता के पास पहुँचता है। पिन ब्लॉक जारीकर्ता सिस्टम में बैक के पास उपलब्ध सूचना का उपयोग करके उत्पन्न होता है। दोनों पिन ब्लॉक की तुलना की जाती है और यदि मिलान हुआ तो पिन प्रमाणीकरण सफल होता है।

सीवीवी या सीवीसी: यह आपके कार्ड से जुड़ा तीन अंकों का कोड है और इसी सीवीवी2/सीवीसी2 कोड का एक प्रारूप आपके कार्ड के पीछे छपा रहता है । यह तीन अंकों का कोड केवल कार्ड प्लास्टिक पर उपलब्ध है और सीवीवी/सीवीसी या सीवीवी 2/सीवीसी2 (सीएनपी लेनदेन के लिए) की उपस्थिति का मतलब है कि विवरण प्रदान करने वाला व्यक्ति कार्ड प्लास्टिक का धारक है।

यह बहुत महत्वपूर्ण है कि लेनदेन के समय कार्ड-विवरण कैप्चर पेज को छोड़कर किसी भी व्यक्ति के साथ पिन और सीवीवी की जानकारी साझा नहीं करनी चाहिए।

२ कारक प्रमाणीकरण (2 फैक्टर ऑथेंटिकेशन): आरबीआई के जनादेश के अनुसार भारत में सभी कार्ड ट्रांजैक्शन को ऑथेंटिकेशन के 2 कारकों के साथ प्रोसेस किया जाता है। आमतौर पर ये दो कारक नीचे दिए तीन कारकों में से किसी दो का संयोजन हैं:

१. आपके पास क्या है? कार्ड की दुनिया में यह आमतौर पर आपका कार्ड-प्लास्टिक होता है या यदि आप अपने पंजीकृत मोबाइल डिवाइस के माध्यम से लेनदेन कर रहे हैं, तो यह आपका मोबाइल डिवाइस हो सकता है।

२. आप क्या जानते हैं? आपके पिन या पासवर्ड इस श्रेणी में आते हैं। यह एक गुप्त जानकारी है जिसे केवल आप और आपके कार्ड जारीकर्ता जानते हैं और मान्य कर सकते हैं।

३. आप कौन हैं? प्रमाणीकरण के सभी बायोमेट्रिक रूप इस श्रेणी में आ जाएंगे। सबसे आम बॉयोमीट्रिक आपका फिंगर प्रिंट है। भविष्य में हम आँख की पुतली, आवाज, व्यवहार, चेहरा आदि को भी प्रमाणीकरण के लिए इस्तेमाल किया जाना देख सकते हैं ।

वर्तमान में कार्ड लेनदेन के मामले में ये दो कारक आपके कार्ड प्लास्टिक और पिन हैं, जबकि कार्ड के बगैर लेनदेन के मामले में यह आपके कार्ड विवरण (कार्ड संख्या, समाप्ति की तारीख और सीवीवी2/सीवीसी2) और ओटीपी या पासवर्ड हैं।

~ मर्चेंट द्वारा नियंत्रण ~

पीओएस टर्मिनल: पीओएस डिवाइस के निम्नलिखित घटक होते हैं: (१) कार्ड रीडर (२) कुंजी पैड (की-पैड), (३) नेटवर्क कनेक्टिविटी, (४ ) मेमोरी स्टोरेज और (५ ) रसीद प्रिंटर। कार्ड रीडर और की-पैड डेटा प्रवेश के समय ही उसे एन्क्रिप्ट कर देते हैं। मेमोरी में इस जानकारी को एन्क्रिप्टेड रूप में संग्रहीत किया जाता है और जैसे ही व्यापारी निपटान की प्रक्रिया करता है, डेटा मेमोरी से हटा दिया जाता है। इस नेटवर्क पर संचार एक संरक्षित लाइन के माध्यम से एन्क्रिप्टेड प्रारूप में होता है। रसीद प्रिंट करते समय आपके कार्ड नंबर जैसी संवेदनशील जानकारी को मास्क किया जाता है।

कार्ड लेनदेन के लिए उपयोग किए जाने वाले एन्क्रिप्शन तर्क को ‘ट्रिपल-डीईएस’ या ‘3डीईएस’ कहा जाता है; जो अभी प्रयोग में आ रहे सबसे उन्नत डेटा एन्क्रिप्शन मानक में से एक है। प्रत्येक टर्मिनल के लिए यूनिक एन्क्रिप्शन का उपयोग किया जाता है, और डायनामिक अपडेट किया जाता है ताकि किसी भी संभावित खतरे से ‘की-लेवल’ पर ही निपटा जा सके।

वॉइड और वापसी

वॉइड और वापसी का उपयोग व्यापारी द्वारा किसी लेनदेन को पूर्ववत (‘अनडू’) करने के लिए किया जाता है। उदाहरण के लिए यदि व्यापारी ने आपके कार्ड को गलत राशि के लिए स्वाइप किया है या आपने भुगतान करने के तुरंत बाद लेनदेन के बारे में अपना मन बदल लिया है, व्यापारी टर्मिनल मेमोरी से उस लेनदेन को रिकॉल करके रद्द कर सकता है। इस प्रक्रिया को वॉइड कहा जाता है और इस मामले में जब व्यापारी निपटान प्रक्रिया करते हैं तो यह लेनदेन वहाँ से छोड़ दिया जाता है यानि आगे प्रोसेस नहीं किया जाता है। जारीकर्ता किसी भी दावे की अनुपस्थिति में तय निपटान समय सीमा समाप्त होने के बाद ग्राहक के खाते में लेनदेन को स्वचालित रूप से उलट देता है।

यदि व्यापारी ने मशीन पर निपटान प्रोसेस कर दिया है और डिवाइस से लेनदेन हटा दिया गया है, तो इसे रद्द/शून्य नहीं किया जा सकता है। इस मामले में व्यापारी रिफंड प्रोसेस करता है, यानी व्यापारी खाते को डेबिट करके ग्राहक खाते को क्रेडिट करने के लिए निर्देश भेजता है। जब व्यापारी इस लेनदेन को व्यवस्थित करता है तो इंटरचेंज के माध्यम से अधिग्रहण कर्ता द्वारा जारीकर्ता को उचित क्रेडिट निर्देश दिया जाता है। इन दिनों इंटरचेंज ‘इंस्टेंट’ रिफंड प्रोसेस करने के तरीके लेकर आए हैं ।

चार्जबैक

जैसा कि अब आप जानते हैं कि कार्ड जारी करने और लेनदेन प्रसंस्करण के समय सुरक्षित लेनदेन सुनिश्चित करने के लिए कई नियंत्रण हैं। ‘चार्जबैक’ लेनदेन के बाद ग्राहक के हितों की रक्षा करने की एक प्रक्रिया है। चार्जबैक प्रक्रिया के तहत यदि डुप्लीकेट बिलिंग, प्रदान नहीं की गई सेवाओं, वितरित नहीं किए गए सामान आदि जैसे लेन-देन के साथ कोई प्रॉब्लम है, तो उपभोक्ता अपने दावे का समर्थन करने वाले सभी साक्ष्यों के साथ अपने जारीकर्ता तक विवाद पहुँचा सकता है। ऐसे मामलों में जारीकर्ता इंटरचेंज के जरिए अधिग्रहणकर्ता के माध्यम से व्यापारी से संपर्क करते हैं और व्यापारी को आवश्यक सबूत प्रदान करने या विवाद को स्वीकार करने और लेनदेन को रिवर्स करने के लिए कहते हैं। व्यापारी डिलीवरी पुष्टि, भुगतान रसीद आदि के रूप में सबूत प्रदान कर सकता है। यदि व्यापारी यह साबित करने में असमर्थ है कि यह एक वास्तविक शुल्क था, तो मामला ग्राहक के पक्ष में बंद कर दिया जाता है और लेनदेन उलट जाता है। यदि व्यापारी यह साबित करने में सक्षम है कि शुल्क वास्तविक था, तो विवाद व्यापारी के पक्ष में बंद किया जाता है।

शून्य देयता

यदि आप अपने कार्ड के साथ भेजी गई सभी अध्ययन सामग्री को पढ़ते हैं, तो कई मामलों में आपको ‘शून्य देयता’ (जीरो लायबिलिटी) के रूप में लेबल किया गया अनुभाग मिलेगा। शून्य देयता स्टोर में की गई आपकी खरीद, या टेलीफोन, ऑनलाइन या मोबाइल और एटीएम लेनदेन के माध्यम की गई आपकी खरीद पर लागू होती है। कार्डधारक के रूप में, आपको अनधिकृत लेनदेन के लिए जिम्मेदार नहीं ठहराया जाएगा यदि:

१. आपने अपने कार्ड को चोरी या खोने से बचाने के लिए पर्याप्त सुरक्षा उपाय किये हैं

२. आपने तुरंत अपने वित्तीय संस्थान को नुकसान या चोरी की सूचना दी है

यदि आपको लगता है कि आपके खाते का अनधिकृत उपयोग किया गया है और आप ऊपर की शर्तों को पूरा करते हैं, तो यह जानकर चिंतामुक्त रहें करें कि आपके पास शून्य देयता वादे की सुरक्षा है। कृपया इस खंड को अपने कार्ड किट में ध्यान से पढ़ें और सुनिश्चित करें कि आप इसे समझ लें।

हॉटलिस्टिंग

कृपया अपने कार्ड के नुकसान या अपने कार्ड पर किसी भी संदिग्ध गतिविधि की रिपोर्ट करने के लिए उपलब्ध सबसे तेज़ माध्यम से अपने बैंक से संपर्क करें। हर कार्ड जारीकर्ता यह सुनिश्चित करता है कि टेलीफोन कॉल के माध्यम से इसकी रिपोर्ट करने के तरीके उपलब्ध रहें; जैसे एक समर्पित फोन नंबर (कृपया इस नंबर को अपने साथ रखें), मोबाइल बैंकिंग, इंटरनेट बैंकिंग आदि।

एक संदिग्ध गतिविधि का क्या मतलब हो सकता है? इसके कुछ उदाहरण इस प्रकार हैं:

१. आपका अपने खाते में किसी ऐसी गतिविधि के बारे में एसएमएस/ई-मेल प्राप्त करना जिसके बारे में आपको जानकारी नहीं है

२. एक एसएमएस/ई-मेल प्राप्त करना जो आपको उस लेनदेन के लिए उत्पन्न ओटीपी के बारे में सूचित करता है जिसे आपने शुरू नहीं किया था

३. कोई व्यक्ति आपको फोन करके आपके कार्ड के बारे में संवेदनशील जानकारी जैसे कार्ड नंबर, सीवीवी, पिन, ओटीपी आदि के बारे में पूछताछ करता है। कोई भी बैंक कभी भी किसी व्यक्ति को फोन कॉल पर साझा करने के लिए यह जानकारी नहीं पूछता है।

आशा है यह जानकारी आपके लिए उपयोगी रही है और आप अगली बार खरीदारी के समय भुगतान के लिए अपने कार्ड का उपयोग करने के बारे में अधिक आश्वस्त हैं। अगले भाग में कार्ड की दुनिया में हो रही धोखाधड़ी के विभिन्न प्रकारों और अपने आप को उनसे बचाने के तरीकों को कवर किया जाएगा।

Thoughts on RBI Draft Paper on NUE for Retail Payment Systems

On 10th Feb, 2020 Reserve Bank of India released a paper on ‘draft framework for authorisation of a pan-India New Umbrella Entity (NUE) for Retail Payment Systems’ for public comments. RBI has invited comments from all stakeholders by February 25th, 2020.

In 2005, when I had started my career from HDFC Bank, there were multiple ATM networks active in the country. Apart from Visa and MasterCard, there was one ATM network run by Euronet, where (I think) 16 banks were participating, and there was another operated by FSS (The entity was walled FSS Net), where (I don’t remember the number of banks) were participating. Apart from these some banks were having bilateral arrangements with other banks for sharing of ATM infrastructure. Around the same time another ATM network by the name of NFS was getting active, which was run by IDRBT. Most of the banks slowly started joining NFS network and with time it became the largest domestic ATM network in India. It was about this time, two things happened; control of NFS network was transferred from IDRBT to a newly formed entity called NPCI and RBI had put a stop to all the bilateral ATM sharing arrangements. From this point onward NPCI became the source of almost all the innovations in retail payments starting with RuPay, IMPS, AEPS, APBS to more recent UPI, BHIM, BBPS, eNACH, NCMC and NETC etc. I had been very fortunate to have balcony seat to many of these stories by virtue of being a part of HDFC Bank and then Kotak Bank and Jio Payments Bank.

The journey of NPCI from NFS ATM network to today controlling almost 60% of retail electronic payment transactions by volume (please note that RuPay Credit Card is a very recent phenomenon and numbers there are still dominated by Visa and MasterCard followed by American Express and Diners) has been really exciting and in many ways the best thing to happen to Indian digital payments ecosystem. Having said that the amount of influence NPCI today commands is really dangerous and while NPCI claims to be very open to suggestion and ideas, I have personally seen on many occasions that best idea didn’t win due to various factors.

With introduction of NUE there is a possibility of many more innovative payment solutions to be envisioned and implemented, which are more suitable for Indian audience. This will also make NPCI work even harder to continue doing the good work they have been doing and not become complacent. Few key areas I can clearly see new NUEs to focus on would be building specialized and low cost solutions for business correspondent network, which is the back bone of entire Financial Inclusion story in India and still does not command the attention that it deserves from various larger players in the ecosystem. Another very important area that has been demanding attention and has clearly been mentioned in RBIs paper is remittances. There are so many migrant workers, who earn in Cash and need to send money to their families in their native places. Cash is still the biggest mode of transaction today in India and there is clearly scope to do more.

I will be looking at organizations like Euronet, FSS, AGS, TATA PSL, NSDL on one hand and PineLabs, Innoviti, mSwipe etc to be eager to go for this. One organization that has been at the center of many innovations happening in India iSPIRT to play a key role in all this. My only advice to anyone considering becoming NUE would be to let go of the traditional card protocols (think beyond iso 8583) and go back to drawing board before designing their solutions. In the end payment is all about debiting one account and crediting another, sounds like simple stuff. The key to any solution would be how simple the final offering remains.

This could also be a move in the direction of having specialized entities enabling interoperability for different modes of payments or use cases. For example Billdesk can attempt to become the go to entity for all things bill-payment. Another NUE can appear specializing the interoperability of mobile wallets. As I have mentioned above, there is a clear scope of specialized offering the business correspondent and self help group area, which has been the key to Financial inclusion in India so far. Hell, why cannot even bank branches be interoperable? Can a Kotak customer walk into and SBI branch and get his passbook updated, earning additional revenue for SBI in the process? The possibilities are endless, if we decide to think outside the box.

Few questions, will NUE as private entities be allowed to user Aadhaar authentication? What will be the exact role of NPCI in all this? Will NUEs be allowed to perform other business activities, for example can NSDL continue to offer e-Sign services as part of same business or have to set-up a separate entity, if they decide to go for it? More clarity should emerge after RBI releases final framework after reviewing everyone’s feedback post 25th Feb, 2020.

Why do I think Zero MDR is a good move?

Imagine a scenario without banks, everyone earns and spends in cash. There are no charges to be paid to anyone. If you are supposed to earn 100 Rs for a service offered, you would earn 100 Rs and when you purchase an item or service worth 100 Rs, you would pay 100 Rs for the same. Merchant earns the exact amount paid by the customer without any deductions in the process. Now this merchant collects bundles of cash everyday so he needs to spend money in handling that much cash. Maybe he will have to buy a secure vault to store it or even hire a security guard to protect it all the time. When he is transporting all that cash, he needs to spend on secure transit. All that would cost merchant some money, which has been the justification for charging MDR. Acquirer told the merchants, by accepting payments digitally we will manage the cash worries for you hence saving you huge cost in the process thus you should compensate us by way of paying us in the form of MDR.

However the problem is, in India only banks are allowed to be the acquirers, who are the custodians of all the money. That means customers as well as merchants keep their money in the books of the banks, meaning cost of transferring the money digitally is much cheaper compared when compared to cash for banks. Since the banks are custodians of all the money and they have the option to reinvest that money primarily by way of lending it to borrowers and charge interest on that money. Typically banks charge anywhere between 8% (home loan) to 36% (credit card roll-over) on the money they lend and a small portion of that around 3% (Savings A/C) -7% (Term Deposits) is passed on to the customer. Rest of the money is supposed to be spend on various expenditures of running the bank. These expenditures should also include building, managing and maintaining the entire payment infrastructure. A fee for allowing customers to access their own funds (on these very funds the entire bank is existing) in any form is unfair.

Specially in case of UPI, cost of merchant acquiring is almost zero. Instead of a PoS machine, which costs somewhere between 1500 Rs (mPoS) to 20,000 Rs (fancy PoS devices with multiple other supporting features) a UPI merchant needs a QR code, which can be printed and attached to a fancy plastic display in less than 100 Rs. In case of PoS, transactions are settled in two steps, authorization and settlements thus requiring an operations team to manage the reconciliation and payments processing, while in case of UPI the transaction is settled real time directly in merchant’s account hence the need for large operations teams and systems is eliminated. I do not have any numbers to compare on disputes/chargebacks but the going by the fundamental design of UPI, the possibility of disputes in UPI are much lesser compared to card world hence requiring even lesser operational expenditure.

When a bank outsources their ATM management business to a third party partner, they pay that third party. The third party is not expected to make fee income from customers. Similarly CC Avenue, Razorpay, Pinelabs of the world should be treated as third parties whom banks have outsourced the job of setting up merchant infrastructure and banks should pay these players for the services rendered at fair price, like they would for any other technology or operations outsourcing partner. Banks are making enough money to pay for this service. Based on some figure being floated around in various media sources I have learned that this zero MDR for RuPay and UPI will put burden of around 1800 Cr on the industry. Can someone remind me the profit made by HDFC Bank in last quarter?

In fact I am saying why should it be applicable for selective merchant base, this should be the case across all merchants. Our banking system is capable enough for paying for their service in order to get the balances from these merchant in their current accounts so that they can make float income on that money.

Another logic given to merchants for demanding MDR is that a card in the hand of customer increases his/her purchasing capacity hence increase in sales for the merchant. That logic primarily applies for Credit Cards and the current mandate leaves them untouched. Maybe a better way to go for banks would be to push Credit Cards. India is still super under penetrated when it comes to credit product and the scope is enormous. The business Bajaj Finance has built on EMI product is proof enough that banks have been failing miserably in exploiting this opportunity. My suggestion would be that banks get their act together, get off their high horse and start optimizing their processes and utilizing their resources better to find efficient ways to increase their revenue by serving their customers better rather than trying to build a fee income. In fact I would rather worry about a bank that is earning a significant portion of their revenue from various fees.

Having stated above, the way most of the players in the market are approaching this entire thing is flowed in my opinion. Banks are refusing to compensate the third party payments processors creating a huge dent in their revenue thus leaving them no choice but to compromise on their core business by creating other parallel businesses in order to generate sustainable revenue streams, which in the long run will be disastrous for the overall payments business. Ideally since banks are the only parties making money from the circulation of money during transaction should own up to their responsibility and compensate the payment providers fairly for their contribution in creating the ecosystem for bank’s customers to use the funds he/she has parked in the bank seamlessly; the way they would compensate any other service provider of theirs.

Above proposed arrangement is a significant shift from common practice prevalent for years, hence expecting such shift overnight would be a folly. Keeping that in mind I propose as an interim arrangement government bears part of the burden with a clear roadmap and visibility towards banks owning the entire cost in due course. Banks are clearly at the seat of power here and instead of exploiting their position to gain more profits and fee income they should instead invest and work for overall growth of digital economy. This move, even if forced should force banks to become more efficient in their processes and start using customers’ data optimally in order to maximize their gains.

Payments Explained: UPI Part 1 (Terminology)

UPI stands for Unified Payments Interface. It’s a system created by NPCI (National Payments Corporation of India) to enable various forms of payments like peer to peer (p2p), merchant payments (p2m) using bank accounts through mobile phone. With increasing adoption of mobile phone there was a need to enable a mobile native payments method that offers superiors user experience and interoperability between banks. While other interchanges were still trying to find a work-around through their traditional card protocols, NPCI decided to go back to basic and conceptualized UPI, which was a system built for mobile users using some inherent capabilities offered by smartphones, like using the mobile device as one factor of authentication (by doing device binding).

They also built it with the thought process of democratizing the innovation by offering open APIs to build up on. The idea behind offering these open APIs was to enable innovators to build their applications/payment experiences suitable for their environment and target customer base the way they deem fit. This thought process gave birth to start-ups like PhonePe, BharatPe and later even larger technology players like Google, Amazon, Truecaller, Whatsapp (they did a pilot but their progress was halted because they were not storing their data locally in India, as per my information they are still working on the same). Recently India’s biggest corporate Reliance also announced their entry in this space by enabling UPI through myJio family of applications. In this series I will try to explain the UPI transactions in detail starting with common terminology followed by transaction flow and various variations of payments built on top of UPI rail and then conclude it with some thoughts on common fraud trends and how to protect oneself from same. Let’s start with common terminology.

Terminology

PSP (Payment Service Provider): A PSP is an entity authorized by NPCI to process UPI based payment transaction. PSPs take care of following functions in a UPI life cycle:

Front-end the transaction flow for the customer
Issue and manage the access credential to the customer to access the mobile app
Register customer on the UPI platform and issue them VPA (Virtual Payment Address)
Maintain the mapping of VPA and Mobile device at their end

VPA (Virtual Payment Address): A VPA is issued by your PSP, that is used to uniquely identify the payer and payee in any transaction. Usually your VPA is username@psp for example abc@okhdfcbank in case of Google Pay, username is abc, selected by user, okhdfcbank is the PSP id issued by NPCI to HDFC Bank, which HDFC Bank has extended to Google Pay as third party processor.

Third Party App: These are typically apps launched by non-bank technology companies like Google, Amazon, Uber etc in partnership with one or more banks as PSP. A list of these apps and their PSP and handle name can be found by visiting this link on NPCI website.

BHIM: BHIM, short for Bharat Interface for Money is an app created by NPCI that lets a user make payments using UPI.

BHIM QR: BHIM QR is a branding used by UPI merchant acquiring PSPs to demonstrate that the particular QR code can be scanned by any app supporting UPI payments i.e. is inter-operable among all PSPs.

BHIM QR Code is nothing but a way to store the VPA of the merchant that is read by your UPI app at the time of scanning. One can use other form factors like NFC or sound wave etc to communicate the merchant VPA to customer’s UPI app to offer differentiated experience, if it is more appropriate for that environment for example maybe a NFC based interaction will be more appropriate for transit use cases like bus, metro etc.

UPI PIN: UPI PIN is the PIN that you input on your UPI app to authenticate yourself with your issuing bank, i.e. the bank that holds your account. You set it up at the time of registration when you link your account with your VPA by verifying the combination of your mobile number and OTP or M-PIN with your issuing bank. This PIN is different that the PIN you use to access your UPI app.

Push Payment: When you scan the QR code of the merchant or use someone’s VPA to send money through your UPI app by debiting your account, such transactions are commonly referred as Push transaction.

Pull Payment: UPI also supports pull payment i.e. you can use someone’s VPA to request money from their account. In this case a request is sent to the concerned person’s UPI app through his PSP and once authorized their account is debited and your account is credited.

Payments Explained: Card Transactions Part 4 (Fraud Prevention)

This is the last part of my series on card payments and in this post I will try to cover some common frauds targeting card users and how one can best protect herself/himself against those.

Skimming: Skimming is the process of stealing your card information at the time of interaction and then misusing that information to fraudulently post transactions on your card. Whenever card is swiped at a PoS or ATM device a fraudster attaches an external card reader to steal the card information at the time of swipe.

Skimmers like these are easily available and can be attached to PoS devices.

One most effective measure taken to prevent this kind of fraud is implementation of CHIP (EMV) cards. RBI has made it mandatory to all the card issuers to ensure all the Debit and Credit Cards issued are CHIP cards. ATM machines are designing their card readers to make installation of any additional external component difficult. However few precautions one can take to safeguard oneself from this are as follows:

Ensure you have sight of your card all the time and the device where the card is being swiped is clearly visible to you and does not have any external component that does not belong is attached to the device.
While using an ATM please ensure there is no external component attached to the card reader of the ATM (many ATMs that still use a magnetic stripe reader use jitter to interrupt the card entry into the card reader that ensures card data is not captured by external device). One way to identify if any external component is attached on the card reader is to look for the light blinking from the card reader. If you cannot clearly see the light at the card reader avoid using that ATM.

These types of frauds are specially prevalent in popular tourism destinations. The logic is that most of the time the card being skimmed is of a tourist and once you are back from your vacation and it becomes very difficult for your to follow through on the crimes committed on your cards in a place you are not native to specially if that place happens to be in a foreign country. Only thing you can do when you are traveling to be extra cautious using your card. I visited Australia recently and noticed that merchants encourage you to swipe/dip or tap your card yourself instead of taking it away from your hands. It is a very good practice.

Phishing: Phishing is exactly what it sounds like (Fishing) fraudster targets a bunch of people in the hopes of getting them to reveal their sensitive information. There is another more entertaining way to learn about Phishing, is watch the very entertaining web-series on Netflix Jamtara, which is based on a tele-calling Phishing racket run by a bunch of young kids from a remote town.

According to Wikipedia definition, “Phishing is the fraudulent attempt to obtain sensitive information such as usernames, passwords and credit card details by disguising oneself as a trustworthy entity in an electronic communication.”

If you receive a call, SMS or e-mail pretending to be from your issuer or any other entity requesting you to share sensitive information like card number, PIN, CVV, OTP, net banking ID and password etc. Only way to protect yourself from this kind of fraud is to never share sensitive details to anyone over any medium. Your bank will never ask for these details over call, sms or e-mail.

Website Spoofing: Fraudsters will create a website that looks like the website of another trusted entity and even have similar url (a very neat trick used by fraudster is to replace of of the characters in the url with another special similar looking special character). One simple way to avoid falling prey to this is avoid clicking on links received on e-mail or sms that asks for sensitive information to be shared, instead type the url yourself.

There are checks and controls implemented by websites to make sure customer recognizes the right page. For example, some websites have a shared image or message that is displayed on the page seeking you to input sensitive information. Like HDFC Bank Netbanking displays a picture and a message selected by you on its log-in page to ensure you are inputting your credentials on an authentic bank page and not some other spoofed website.

Social Engineering: The use of deception to manipulate individuals into divulging confidential or personal information that may be used for fraudulent purposes. Phishing explained above is a type of social engineering. Some other ways of social engineering relevant in this context are Vishing, where fraudsters will mimic the IVR (Interactive Voice Response) of the target organization to convince that organization’s customers into revealing sensitive information and Baiting, where fraudster will send you a link over e-mail or SMS prompting you to click on an infected link with promise of certain reward or threat of some loss.

There are no prince in Nigeria or warlords in Sudan dying to share their wealth with you, neither you have won any Coca-Cola or Reader’s Digest lottery. RBI or Income Tax departments are never going to call you to credit your account neither is Modi government giving you fifteen lac rupees in your account provided you share your account or net banking credentials with them. To receive LPG subsidy you just need to link your Aadhaar to your bank account and nothing else.

Money Mule: A money mule, sometimes also called as “smurfer” is a person who helps fraudsters transfer money acquired illegally. If someone approaches you with a story that he needs to transfer a fortune and want to use your account to park some funds and they will offer huge reward just for allowing the money to pass through your account or once the money is deposited in your account you need to withdraw cash and hand deliver it to someone in person, you are being recruited as a money mule in an elaborate fraud scheme.

When money is moved digitally, it leaves a trail and that can be used to identify and arrest the fraudster. To avoid this fraudsters create an elaborate trail of movement by passing the money through various money mule accounts and convincing these unsuspecting people into handing over the money in the form of cash at an unsupervised location. If you act as a money mule then you become a co-conspirator in the fraud and will be liable for any criminal proceedings that attracts. So avoid falling into becoming a criminal for some monetary reward.

Protect your Mobile Phone: These days your mobile phone has become very important when processing digital transactions. In many cases your mobile device is used as a mode of authentication, most of the time an OTP received on your mobile phone is used as 2nd factor authentication and many times websites and mobile apps store your card details (called card on file in payments world) in order to provide you a convenient user experience.

Now imagine a scenario where you have lost your smart phone and some fraudster has gotten hold of the device. Your phone is unlocked because you never set-up any access control like face, fingerprint, pattern or password to lock your phone when not in use. Fraudster notices that you have installed your telecom operator’s app on your phone and have your card credentials stored there. He sets up a shop offering cheap recharge to prepaid customers of that telco. He collects cash from the customers to recharge their prepaid mobile number and used your card stored in the app and OTP delivered on the device to make the payment. By the time you would report this and authorities catch up to him he would have shut the shop and run away. The only thing protecting you at this moment is your three digit cvv2/cvc2, if somehow he manages to find out that or guess that number you have no protection.

My only advice to you in this case is a. store your mobile number only at the apps/website you frequently use, b. set up an access control on your smartphone be it PIN, Pattern, Fingerprint or Face ID have some protection, c. don’t lose your phone and if you do immediately call your telco to block the number and also your bank to block your cards.

Physical Interaction: At last one very important thing, whenever you are providing photocopy of any KYC documents to anyone please make sure you sign it with date and purpose. The logic is to avoid misuse of your document from giving any instruction to your bank through their branch for example change of address, reissue of card, reissue of PIN, new cheque book etc. Bank branches typically ask for an identity proof to be attached with any written instructions to ensure the instruction has been received from authorized party.