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

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.