Regulating HFT in India

The Securities and Exchange Board of India (SEBI) has set a cat among the HFT (High Frequency Trading) pigeons by proposing seven measures to curb the impact of HFT and improve “real liquidity” in the stock markets.

The big problem with HFT is that algorithms tend to cancel lots of orders – there might be a signal to place an order, and even before the market has digested that order, the order might get cancelled. This results in an illusion of liquidity, while the constant placing and removal of liquidity fucks with the minds of the other algorithms and market participants.

There has been a fair amount of research worldwide, and SEBI seems to have drawn from all of them to propose as many as seven measures – a minimum resting time between HFT orders, matching orders through frequent batch auctions rather than through the order book, introducing random delays (IEX style) for orders, randomising the order queue periodically, capping order-to-trade ratio, creating separate queues for orders from co-located servers (used by HFT algorithms) and review provision of the tick-by-tick data feed.

While the proposal seems sound and well researched (in fact, too well researched, picking up just about any proposal to regulate stock markets), the problem is that there are so many proposals, which are all pairwise mutually incompatible.

As the inimitable Matt Levine commented,

If you run batch auctions and introduce random delays and reshuffle the queue constantly, you are basically replacing your matching engine with a randomizer. You might as well just hold a lottery for who gets which stocks, instead of a market.

My opinion this is that SEBI shouldn’t mandate how each exchange should match its orders. Instead, SEBI should simply enable individual exchanges to regulate the markets in a way they see fit. So in my opinion, it is possible that all the above proposals go through (though I’m personally uncomfortable with some of them such as queue randomisation), but rather than mandating exchanges pick all of them, SEBI simply allows them to use zero or more of them.

This way, different stock exchanges in India can pick and choose their favoured form of regulation, and the market (and market participants) can decide which form of regulation they prefer. So you might have the Bombay Stock Exchange (BSE) going with order randomisation, while the National Stock Exchange (NSE) might use batch auctions. And individual participants might migrate to the platform of their choice.

The problem with this, of course, is that there are only two stock exchanges of note in India, and it is unclear if the depth in the Indian equities market will permit too many more. This might lead to limited competition between bad methods (the worst case scenario), leading to horrible market inefficiencies and the scaremongers’ pet threat of trading shifting to exchanges in Singapore or Dubai actually coming true!

The other problem with different exchanges having different mechanisms is that large institutions and banks might find it difficult to build systems that can trade accurately on all exchanges, and arbitrage opportunities across exchanges might exist for longer than they do now, leading to market inefficiency.

Then again, it’s interesting to see how a “let exchanges do what they want” approach might work. In the United States, there is a new exchange called the Intercontinental Exchange (IEX) that places “speed bumps” over incoming orders, thus reducing the advantage of HFTs. IEX started only recently, after major objections from incumbents who alleged they were making markets less fair.

With IEX having started, however, other exchanges are responding in their own ways to make the markets “fairer” to investors. NASDAQ, which had vehemently opposed IEX’s application, has now filed a proposal to reward orders by investors who wait for at least once second before cancelling them.

Surely, large institutions won’t like it if this proposal goes through, but this gives you a flavour of what competition can do! We’ll have to wait and see what SEBI does now.

Uber’s anchoring problem

The Karnataka transport department has come out with a proposal to regulate cab aggregators such as Uber and Ola. The proposal is hare-brained on most  counts, such as limiting drivers’ working hours, limiting the number of aggregators a driver can attach himself to and having a “digital meter”. The most bizarre regulation, however, states that the regulator will decide the fares and that dynamic pricing will not be permitted.

While these regulations have been proposed “in the interest of the customer” it is unlikely to fly as it will not bring much joy to the customers – apart from increasing the number of auto rickshaws and taxis in the city through the back door. I’m confident the aggregators will find a way to flout these regulations until a time they become more sensible.

Dynamic pricing is an integral aspect of the value that cab aggregators such as Uber or Ola add. By adjusting prices in a dynamic fashion, these aggregators push information to drivers and passengers regarding demand and supply. Passengers can use the surge price, for example, to know what the demand-supply pattern is (I’ve used Uber surge as a proxy to determine what is a fair price to pay for an auto rickshaw, for example).

Drivers get information on the surge pricing pattern, and are encouraged to move to areas of high demand, which will help clear markets more efficiently. Thus, surge pricing is not only a method to match demand and supply, but is also an important measure of information to a cab aggregator’s operations. Doing away with dynamic pricing will thus stem this flow of information, thus reducing the value that these aggregators can add. Hopefully the transport department will see greater sense and permit dynamic pricing (Disclosure: One of my lines of business is in helping companies implement dynamic pricing, so I have a vested interest here. I haven’t advised any cab aggregators though).

That said, Uber has a massive anchoring problem, because dynamic pricing works only in one way. Anchoring is a concept from behavioural economics where people’s expectations of something are defined by something similar they have seen (there is an excellent NED Talk on this topic (by Prithwiraj Mukherjee of IIMB) which I hope to upload in its entirety soon). There are certain associations that are wired in our heads thanks to past information, and these associations bias our view of the world.

A paper by economists at NorthEastern University on Uber’s surge pricing showed that demand for rides is highly elastic to price (a small increase in price leads to a large drop in demand), while the supply of rides (on behalf of drivers) is less elastic, which makes determination of the surge price hard. Based on anecdotal information (friends, family and self), elasticity of demand for Uber in India is likely to be much higher.

Uber’s anchoring problem stems from the fact that the “base prices” (prices when there is no surge) is anchored in people’s minds. Uber’s big break in India happened in late 2014 when they increased their discounts to a level where travelling by Uber became comparable in terms of cost to travelling by auto rickshaw (the then prevalent anchor for local for-hire public transport).

Over the last year, Uber’s base price (which is cheaper than an auto rickshaw fare for rides of a certain length) have become the new anchor in the minds of people, especially Uber regulars. Thus, whenever there is a demand-supply mismatch and there is a surge, comparison to the anchor price means that demand is likely to drop even if the new price is by itself fairly competitive (compared to other options at that point in time).

The way Uber has implemented its dynamic pricing is that it has set the “base price” at one end of the distribution, and moves price in only one direction (upwards). While there are several good reasons for doing this, the problem is that the resultant anchoring can lead to much higher elasticity than desired. Also, Uber’s pricing model (more on this in a book on Liquidity that I’m writing) relies upon a certain minimum proportion of rides taking place at a surge (the “base price” is to ensure minimum utilisation during off-peak hours), and anchoring-driven elasticity can’t do this model too much good.

A possible solution to this would be to keep the base fare marginally higher, and adjust prices both ways – this will mean that during off-peak hours a discount might be offered to maintain liquidity. The problem with this might be that the new higher base fare might be anchored in people’s minds, leading to diminished demand in off-peak hours (when a discount is offered). Another problem might be that drivers might be highly elastic to drop in fares killing the discounted market. Still, it is an idea worth exploring – in my opinion there’s a sweet spot in terms of the maximum possible discount (maybe as low as 10%, but I think it’s strictly greater than zero)  where the elasticities of drivers and passengers are balanced out, maximising overall revenues for the firm.

We are in for interesting days, as long as stupid regulation doesn’t get in the way, that is.

Hyperlocal and inventory intelligence

The number of potential learnings from today’s story in Mint (disclosure: I write regularly for that paper) on Foodpanda are immense. I’ll focus on only one of them in this blog post. This is a quote from the beginning of the piece:

 But just as he placed the order, one of the men realized the restaurant had shut down sometime back. In fact, he knew for sure that it had wound up. Then, how come it was still live on Foodpanda? The order had gone through. Foodpanda had accepted it. He wondered and waited.

After about 10 minutes, he received a call. From the Foodpanda call centre. The guy at the other end was apologetic:

“I am sorry, sir, but your order cannot be processed because of a technical issue.”

“What do you mean technical issue?” the man said. “Let me tell you something, the restaurant has shut down. Okay.”

I had a similar issue three Sundays back with Swiggy, which is a competitor of Foodpanda. Relatives had come home and we decided to order in. Someone was craving Bisibelebath, and I logged on to Swiggy. Sure enough, the nearby Vasudev Adigas was listed, it said they had Bisibelebath. And so I ordered.

Only to get a call from my “concierge” ten minutes later saying he was at the restaurant and they hadn’t made Bisibelebath that day. I ended up cancelling the order (to their credit, Swiggy refunded my money the same day), and we had to make do with pulao from a nearby restaurant, and some disappointment on having not got the Bisibelebath.

The cancelled order not only caused inconvenience to us, but also to Swiggy because they had needlessly sent a concierge to deliver an impossible order. All because they didn’t have intelligence on the inventory situation.

All this buildup is to make a simple point – that inventory intelligence is important for on-demand hyperlocal startups. Inventory intelligence is a core feature of startups such as Uber or Ola, where availability of nearby cabs is communicated before a booking is accepted. It is the key feature for something like AirBnb, too.

If you don’t know whether what you promise can be delivered or not, you are not only spending for a futile delivery, but also losing the customer’s trust, and this can mean lost future sales.

Keeping track of inventory is not an easy business. It is one thing for an Uber or AirBnB where each service provider has only one product which is mostly sold through you. It is the reason why someone like Practo is selling appointment booking systems to software – it also helps them keep track of appointment inventory, and raise barriers to entry for someone else who wants the same doctor’s inventory.

The challenge is for companies such as Grofers or Swiggy, where each of their sellers have several products. Currently it appears that they are proceeding with “shallow integration”, where they simply have a partnership, but don’t keep track of inventory – and it leads to fiascos like mentioned above.

This is one reason so many people are trying to build billing systems for traditional retailers – currently most of them do their books manually and without technology. While it might still be okay for their business to continue doing that (considering they’ve operated that way for a while now), it makes it impossible for them to share information on inventory. I’m told there is intense competition in this sector, and my money is on a third-party provider of infrastructure who might expose the inventory API to Grofers, PepperTap and any other competitor – for it simply makes no sense for a retailer to get locked in to one delivery company’s infrastructure.

Yet, the problem is easier for the grocery store than it is for the restaurant. For the grocery store, incoming inventory is not hard to track. For a restaurant, it is a problem. Most traditional restaurants are not used to keeping precise track of food that they prepare, and the portion sizes also have some variation in them. And while this might seem like a small problem, the difference between one plate of kesari bhath and zero plates of kesari bhaths is real.

Chew on it!

Market depth, pricing and subsidies

A few days back I had written about how startups should determine how much to subsidise their customers during the growth phase – subsidise to the extent of the long-term price. If you subsidise too much initially, elasticity might hit you when you eventually have to raise prices, and that can set you back.

The problem is in determining what this long-term sustainable price will be. In “one-sided markets” where the company manufactures or assembles stuff and sells it on, it is relatively easy, since the costs are well known. The problem lies in two-sided markets, where the long-term sustainable price is a function of the long-term sustainable volume.

A “bug” of any market is transaction costs, and this is especially the case in a two-sided market. If you are a taxi driver on Ola or Uber platform, the time you need to wait for the next ride or distance you travel to pick up your next customer are transaction costs. And the more “liquid” the market (more customers and more drivers), the lesser these transaction costs, and the more the money you make.

In other words, the denser a market, the lower the price required to match demand and supply, with the savings coming out of savings in transaction costs.

So if you are a two-sided market, the long-term sustainable price on your platform is a function of how big your market will be, and so in order to determine how much to subsidise (which is a function of long-term sustainable price), you need to be able to forecast how big the market will be. And subsidise accordingly.

It is well possible that overly optimistic founders might be too bullish about the eventual size of their platform, and this can lead to subsidising to an extent greater than the extent dictated by the long term market size. And some data points from the Indian “marketplace industry” show that this has possibly happened in India.

Having remained credit card only for a long time now, Uber has started accepting cash payments – in order to attract customers who are not comfortable transacting money online. This belated opening shows that Uber perhaps didn’t hit the numbers they had hoped to, using their traditional credit card / wallet model.

Uber has problems on the driver side, too, with an increasing number of its drivers turning out to be rather rude (this is anecdata from several sources, I must confess), refusing rides, fighting with passengers, etc. Competitor Ola has started buying cars and loaning them to drivers, perhaps indicating that the driver side of the market hasn’t grown to their expectations. They are all indicative of overestimation of market size, and an attempt to somehow hit that size rather than operating at the lower equilibrium.

So an additional risk in running marketplaces is that if you overestimate market size, you might end up overdoing the subsidies that you provide to build up the market. And at some point in time you have to roll back those subsidies, which might lead to shrinkage of the market and a possible death spiral.

Now apply this model to your favourite marketplace, and tell me what you think of them.

The service marketplace paradox

This came out of a conversation a few weeks back, and resurfaced in a conversation yesterday. There is a fundamental paradox in service marketplaces – the more useless the general quality of service is, the more useful the marketplace. Let me explain.

Let us take the market for plumbers, for example. There are several hyperlocal service marketplaces in India (like HouseJoy or LocalOye) which supply plumbers on demand. Their biggest challenge is offline transactions (as this article about US-based HomeJoy describes) – once two sides of the market are introduced to each other, they take further transactions online.

Thus, there is a huge amount of activity and value taken offline once the introduction has been made, as the long tail of the client/pro relationship takes hold. Clients are perpetually motivated to move their pro relationships off platform, because it’s one less intermediary to go through to directly access the pros they love.

In other words, once I’ve discovered a plumber through HouseJoy (for example), and find his work to be good, the next time I need a plumber I’ll simply call him rather than call HouseJoy (cutting out the middleman). If the plumber is reliable and produces reasonable service, HouseJoy has practically lost me as a customer for plumbing services for a long time.

On the other hand, if the plumber I used the first time is good but not reliable (doesn’t arrive on time the next time I call him), I’m likely to use HouseJoy (or a competitor)  the next time round. In other words, the worse the service providers are (in terms of reliability, not quality of work), the greater the likelihood of the platform getting business!

This is the fundamental paradox of service marketplaces. When services are reliable, you don’t need a marketplace. So if you need a marketplace only if services are unreliable, the server side of the marketplace is full of unreliable people. The hope, and the value that the marketplace adds, is that by aggregating a bunch of unreliable people, some level of reliability is guaranteed. The question is how sustainable this is.

Think of this another way – the level of reliability offered by a marketplace can be described as the sum of reliability of service providers and reliability of the marketplace itself. So for a given level of overall reliability, the marketplace adds more value if individual service providers are less reliable!

Extending this model to other marketplaces and services is left as an exercise to the reader. Feel free to use the comments section to write your analysis.


Characterising network effects

Met a bunch of people for drinks this evening. Most of the conversation was just okay. But there was this little bit about network effects. Where I figured out how to calculate whether network effects are present in an industry. It all came out of Kingsley claiming that the age of network effects is over, and there are no more network effects left.

The discussion presently moved to how you discover whether there exist network effects in different industries. Does the fact that  Amazon’s marketshare is nowhere close to that of a monopoly mean that there are no network effects in e-commerce marketplaces? Doesn’t Google have network effects in that given the larger number of people searching on the platform, there are more clicks and more opportunity for learning (for Google) and hence better results?

At a point of time in the conversation, I made the statement that Google (in particular and search engines in general) has “partial network effects”, in that more users means more learning and hence more results. And that for this reason Bing or any other competitor can’t match up.

So how can we characterise whether an industry has network effects, and if so, to what degree? Thinking about it, it’s rather simple. In a “normal” non-networked industry, the value of the user base is directly proportional to the number of users. Going by Metcalfe’s Law, in a fully networked industry, the value of the user base is directly proportional to the square of the number of users. An industry with “partial network effects” should surely have its value a power between 1 and 2 of the number of users?

Here’s how we figure out how networked an industry is. Take all the players in the industry and tabulate the size of the user base and the value of each of the players (excluding very small players). Plot them on a log-log plot, and measure the slope. If the slope of this log-log plot is close to 1, it means that the industry is not networked at all. If the slope is close to 2, it means it has “full network effects”. And the numbers in between represent the spectrum of possible values.

Rather simple, isn’t it? This is why I love drinking sessions, for they allow you to unleash such thoughts. Oh, and I “recorded” this thought by sending a WhatsApp voice message with the gist of the above content to Hariba. He replied with “keep them coming” or some such thing, but this was all it was for this evening.

No Chillr, Go Ahead

This is yet another “delayed post” – one that I thought up some two weeks back but am getting down to write only now. 

After some posts that I’ve done recently on the payments system, I decided to check out some of the payment apps, and installed Chillr. This was recommended to me by a friend who has a HDFC Bank account, who told me that the app is now widely used in his office to settle bills among people, etc. Since I too have an account with that bank, I was able to install it.

The thing with Chillr is that currently they are tied up with only HDFC Bank. You can still sign on if you have an account of another bank, but in that case you can only receive (and not send) money through the system. So your incentive for installing is limited.

Installation is not very straightforward since you have to enter some details from your netbanking which are not “usual” things. One is a password that allows you to receive money using the app, and the other is a password that allows you to send money. Both are generated by the bank and sent to your phone as an SMS which the app automatically reads. I understand this is part of the system itself and this part won’t go away irrespective of the app you use.

Once you have installed it, you will then be able to use the app to transfer money to your contacts who are also on the app without requiring to know their account number. The payment process is extremely smooth with an easy to use second factor of authentication (a PIN that you have set for the app, so it is instant), so if more people use it, it can ease a large number of payments, including small payments.

The problem, though, is that it is currently in a “walled garden” in that only customers of HDFC Bank can send money, and hence the uptake of the app is limited. The app allows you to see who on your contact list is there on the app (since that is the universe to which you can send money using the app). The last time I checked, there were four people on the list. One was the guy who recommended me the app, the second was another friend who works in the same organisation as this guy, the third a guy who works closely with banks and the fourth a Venture Capitalist. And my phonebook runs into the high hundreds at least.

In terms of technology, the app is based on the IMPS platform which means that in terms of technology there is nothing that prevents the app from transferring money across banks using its current level of authentication. This is very good news, since it means that once banks are signed on, it is a seamless integration and there are no technological barriers to payment.

The problem, however, is that the sector suffers from the “2ab problem” (read my  argument in favour of net neutrality using the 2ab framework). Different tech companies are signing on different banks (Chillr to HDFC; Ping Pay to Axis; etc.) and such banks will be loathe to sign on multiple tech companies (possibly due to integration issues; possibly due to no compete clauses).

Currently, if HDFC Bank has a users and Axis Bank has b users, and they use Chillr and Ping Pay respectively, the total value added to the system by both Chillr and Ping Pay is proportional to a^2 + b^2 (network effects, Metcalfe’s law and all that). But if these companies merge, or one of them gets the account of the other’s bank, then you have a single system with a+b users, and the value added to the system by the combined payments entity is (a+b)^2 which is a^2 + b^2 + 2 ab. Currently the sector is missing the 2ab. The good news, however, is that there are no tech barriers to inter-bank payments.

Postscript: The title is a direct translation of a popular and perhaps derogatory Kannada phrase.