OCEN: The New Beast in the Fintech Space
--
There is a lot of chatter about Account Aggregators (AA) and how it will change the lending landscape. But there is another piece, dare I say, an equally important piece in the context of SME lending, which the government has been working on. It is called OCEN (pronounced O- Ken), an abbreviation of Open Credit Enablement Network.
The problem in the system
As per various estimates, India has a working capital gap of ~$300Bn-$400Bn. There are quite a few small merchants who are unable to a) raise capital at reasonable rates or b) get money because they do not have physical collateral. However, what they do have is information collateral. They have transacted digitally across platforms, have GST invoices, have their P&L, have been rated on various platforms, and also have some information coming in from the telecom records and healthcare records. There exists a huge chunk of such useful information, but it is very fragmented and distributed on different platforms.
We know that the Account Aggregator Rail is capable of pulling financial information but there is a lot of non-financial information which can also be utilized. For instance, someone might have a cloud kitchen on Zomato and Swiggy with a 4.5 rating. For such folks, the banks will not have any information other than the revenue. To take another example, let’s say there is a logistics company that uses trucks (already collateralized) of a truck operator, who mostly operates on time. What if I say that there is a platform where such information can be used to understand the borrower’s credibility? In other words, one would be awarded for the good work one has done and not just for the tangible collateral that one has.
In the past, several marketplaces like Udaan, Fynd, Amazon, and Flipkart (let’s call them Lending Service Providers — LSPs) faced problems when integrating with banks and NBFCs at the back-end. Because of the different ways in which lending entities evaluate borrowers, one entity cannot serve the borrowing appetite of all the credible lenders. So these marketplaces have to integrate with multiple entities separately. In many cases, the LSPs (someone with a captive audience), needs to do tech integrations with a separate set of APIs for every new tie-up. In certain cases, these tie-ups with the lending entities might be taking place via excel sheets. All of this pushes up the costs of operations and tech management.
One might ask, “Why do these marketplaces care enough to provide lending facilities to their merchants?” The simple answer is — to increase stickiness and improve monetization.
On top of this, every financial institution has a separate onboarding process and lifetime operations management solutions. There is no standardization when it comes to the approval process. It may happen in 2 hours, 2 days or 2 weeks. It requires dedicated time devotion.
Furthermore, it was not feasible for bank providers to go after these small-ticket loans because the unit economics never made sense, and it was challenging to identify credible borrowers, not to mention the difficult collection process.
To solve for such issues, we have some embedded SME lending B2B solutions like Rupifi, but they are very early in the game. The market is large and the problem is huge enough to warrant multiple players.
What does OCEN do?
I will use the same analogy which everyone else is using. OCEN is to SME lending what UPI was to payments. Essentially, OCEN standardizes the processes of the loan applications. It solves for the problem of identification, distribution, and collection. Now, it would happen via a set of standardized APIs. In simple terms, companies with some captive merchant base (LSPs like Zomato, Swiggy, Udaan, Flipkart, Amazon, Fynd, Blackbuck, etc.) would be able to download those STANDARDIZED APIs–currently available on iSpirit–integrate themselves and finally give them to their captive audience (customers, merchants, or even delivery partners). This means that these LSPs (marketplaces) would not need different coding to tie-up with separate lending institutions.
Imagine, for instance, that you are an iPhone owner and you go to someone’s place. It would be similar to knowing that everyone has a charger that can be plugged into your iPhone. You don’t have to worry whether others might only have type-C or type-B. You won’t have to keep your charger in your bag.
Now, in between, we might have someone who manages the integration, acting as a technology service provider because there should be tie-ups with banks. However, that is secondary. The important point is the ease with which this will get executed.
The system would allow the non-financial data (ratings, number of transactions, cash flow with the LSPs, etc.) and the financial data (using AA — GSTIN, ITR, etc.) to be read and processed. All this information can be used to underwrite loans a lot better and can give these companies much more confidence.
Think of it like this — there is a loan applicant who has stellar ratings and transaction history. Now, he can fill in the data, which the back-end is going to process and in 5 minutes, the borrower would have multiple options to choose from.
OCEN would promote cash flow based lending and various types of financial products. Additionally, whenever someone uses the platforms, they have to sign up for e-mandates. Hence, any money that the borrower receives via the transaction on the platform is first paid to the lender and then the remaining is transferred to the bank account. Data sharing via AA provides continuous evaluation of the individuals’ fortune. Fluctuations in the cash flow can therefore be identified in advance.
How it can evolve
We would see data derived operators coming up, which would make sense of the data on the platforms and help in underwriting loans. For instance, on a particular marketplace, a merchant not only provides great products but also delivers on time. There are very few returns on orders. All of this information and more can be used to evaluate the merchant better. For that to happen, someone would have to consume, interpret, and normalize the data. All of this can be done by the data derived provider. LSPs can be data derived providers themselves or a horizontal player may come up later.
There can be a host of other use cases which may crop up:
1. Agrilending: Tomorrow, Bigbasket or Ninjacart can use their data to provide a lending product to farmers, and can also use its data to provide a consumer lending product based on the frequency of purchases.
2. Zomato: It can not only provide access to its listed restaurants but also leverage its data on the delivery partners. The top delivery executives can be rewarded with a lending facility.
3. HRMS: Something like a Darwinbox can use its attendance management software and expense management pieces to provide financial products to the employees of its customers.
4. Advance payment of school fees: Schools can help provide parents with fees management solutions, based on their past payment behaviour. Alternatively, the data can be used by the ERP solutions they are using to provide new financial products.
There can be many more use cases on top of these examples. The only thing required would be imagination.
If you want to discuss more, I’d be happy to talk at raunak@eximiusvc.com.
