Comment on CDSL introduces PIN-based pre-authorisation for selling stocks

Krish commented on 01 Jun 2020, 03:56 PM

Hi, tldr, you and AQ have no idea of the implications of this so-called ideal system described by AQ.

Long version: Hi, there is nothing fake about what I said. Even with Robinhood and Etrade, you are only doing what we’re already doing in India i.e. trading via a power of attorney (POA). Didn’t you know that you had signed a power of attorney when creating an account with Robinhood?

We already have the POA option in India and with Zerodha. This new option is for those who do not wish to sign a POA. It is a decent alternative and a decent reaction to the Karvy scandal where the POA was absolutely misused.

I stated two things – in UK/US, the holdings are directly held by CREST/DTC & that you are only a nominee, and it is very expensive to have a truly personal account where you own the stock directly. It seems that I might have been mistaken reg. DTC wherein the stock is held in your name only, but with CREST that is not the case – you do not own the scrip directly. To do that, you need to spend a lot more on a more personal account (unless things have changed since when I checked last week).

Robinhood’s process is just as simple as what we already have in India, thanks to the advent of tech-savvy discount brokers like Zerodha, Upstox etc. and Aadhaar e-verification options.

But at the end of the day, both Robinhood and ETrade are still just brokers with clearing house permits, and you’re still not opening something directly with the exchange, which is what AQ wanted (“individual would directly approach the exchange to open and account”).

What AQ asked for is borderline ridiculous and pointless: “In an ideal world (which we don’t live in) an individual would directly approach the exchange to open and account. The exchange must do the KYC and other formalities and allow the user to create API keys (which will have access levels to choose from such as trading/ withdrawal etc) and then user hands over the keys to whichever broker they chose to and that should be it.”

I will discuss this objectively, showing that my criticism of this idea is not undue. AQ has absolutely no idea of the security risks of a system like that and fact that if their key is accidentally leaked out, their account may be accessed by yet another third-person without AQ’s permission & knowledge, and used to trade and move funds etc. – since there is no need to do KYC as per AQ’s method.

You may argue that it is the same as a username/password leaking out – and it is not totally incorrect. But with username & password, you can at least get 2FA set up when logging in, so even if the login credentials are leaked out, your 2FA is likely to protect you. On the other hand, with an API, it is not practical to perform 2FA for each transaction. Imagine getting an OTP/random Auth code for each trade you do – the time it will take will be infinitely more than the one-time Pre-authorisation process here.

Perhaps the API authorisation challenge can be handled by generating a reciprocal key at the broker’s end and submitting it to the exchange to prevent unauthorised transactions by third parties. But this might not be legally sufficient – you still might need to provide a POA to allow your broker to execute transactions on your behalf.

Further, the broker may not be able to verify if another person’s API is being used by you, unless additional verification is done by the broker to the exchange. For this, the broker will need to collect and verify your data i.e. perform a KYC anyway, and verify it against what has been submitted at the exchange. While this verification need not be done for each transaction, both the broker and exchange would still need to design a system where any change to the personal data on their side will immediately scrap all API & reciprocal keys generated/stored. Apart from the auto-scrapping, there must also be periodical check to ensure that the data with the broker & the exchange, correlate. Both exchange and broker must periodically ping each other with the data as a fall-back mechanism. Each of these interactions is a server request and adds to the already excessive server load.

Further, the exchange will have to think of and develop several security measures personally for the user, which will divert them from their core activity of being a platform for buying & selling shares and focusing directly on improving their platform. Each action by a user will also create unnecessary extra server load for the exchange and it will have to spend more money (on both hardware and software) for managing the server load as well.

This still does not void the user from the responsibility to periodically verify the number of brokers accessing the API, which is another additional task that can only be performed by the user’s side, not the exchange. Also, if you had not submitted the POA allowing the broker to pass on transaction instructions on your behalf, you will have to approve the transactions that have been performed by you at the day’s end on the exchange account.

So, to sum up:
1) User opens account with exchange, performs KYC.
2) User generates API key.
3) User chooses broker and opens account, performs KYC.
4) User inputs API key from exchange and generates reciprocal key.
5) User inputs reciprocal key from broker into the exchange account.
6) User must periodically verify their API is not being misused.
7) User must approve transactions on the exchange if POA not submitted.
8) Tons of other security work by the exchange & broker.

In short, it is not impossible but is impractical.

But at the end of the day, what is happening here? AQ is expecting us to do manually, all the things that the broker takes care for us when setting up the account. All this to try avoiding a one-time task of entering a PIN once or providing a POA once. That is ridiculous. The scale of work that needs to be done, especially on the security side where one will have to proactively plan against security vulnerabilities due to the new method (in addition to the existing security challenges), makes the idea pointless when a simpler & sufficiently secure format already exists today.

If a system like this considered is ‘easier’ by AQ (what I’ve stated is the bare minimum required for security & legality), good for them. And do note, I have probably understated various other challenges as these steps alone were a hassle to work out. I still haven’t covered how the fund transfers will be managed, for starters.

I wonder if people think this is a game. Click to get money, eh? No actual thought-process and work involved? Can’t do a little grunt work? Can’t appreciate all the progress and security measures introduced, while at the same time keeping things economical and easy-to-use? Nope. The Never Satisfied Generation – NSG.

View the full comment thread »