Earlier this year in July, Nandan Nilekani, founding architect of Aadhaar, announced the launch of a new credit infrastructure called the ‘Open Credit Enablement Network (OCEN) protocol (pronounced ‘O-Ken’). The running analogy is that OCEN would be to lending what UPI was for payments. Ever since then, the entire industry has been abuzz with OCEN.

I know it’s been a while since we wrote but trust me this one should be worth your time. We double click on how OCEN works and dive into what a consumer-facing product based on it might look like.

First up - Why is everyone talking about OCEN? What’s its significance?

You know, here’s a fun story- in the summer of 1956, the Eisenhower administration in the US decided to pass the Federal Aid Highway Act. The goal was simple – to build 41,000 miles of interstate highway network from coast to coast so that if ever there was a nuclear attack by the Soviet Union, it was possible to evacuate cities easily. And thus, America’s massive interstate highway network was born.

Luckily enough, there was no nuclear attack but what did happen as a consequence of the Act, was the spectacular rise of the American automobile industry. The mere existence of the infrastructure created a massive demand for the product (the car).

OCEN is like the highway infrastructure for the lending industry. It is not a switch which you can access, but instead a protocol - just the way HTTP is for the internet. What can be built on top of OCEN is what makes everyone excited.

Most experts believe that it would take at least 2 years for consumer products built on OCEN to hit the market (all with licenses being granted, products being designed and built, bank-specific integrations being made available, etc.), but the game to get ready for it has already started– and boy oh boy is it exciting!

And this is also something that is extremely important for India. As a nation, our government is facing a very high debt burden, most of the country’s population cannot afford the high rate at which they borrow (think unorganized sector where interest rates touch 50% sometimes) and the distribution of organized credit is, at best, asymmetric in favor of the rich.

For a country with a savings rate above 30% of the GDP - the system is clearly inefficient in distributing this capital as credit (which is important for money creation or money multiplication in any capitalist system).

OCEN is a brilliant solution to not just the country’s massive credit need, but the bigger credit distribution problem (important to differentiate the two). It’s not going to magically bring more credit into the system, but will definitely make it much easier for the Next Billion Users and SMEs to access it (and hopefully reduce concentration of capital in the hands of a few.)

To receive more such analysis, in your inbox - do consider subscribing! It’s Free!

So how will OCEN work?

You want a massive rant and API documentation? No, right?

To explain how OCEN works, I whipped up some wireframes for a hypothetical product called “FastLoan” – a consumer facing app that just raised $1mn seed funding (😉) and provides short term loans via its banking partners to small businesses in less time than it takes to make a cup of chai - that too with ZERO PAPERWORK!

The flow is based on the official prototype of the Sahay app, which is a reference put in place by an organisation called CredAll which is a collective of lending ecosystem players to drive cash flow based lending anda has been set up to ensure the implementation of the OCEN. Think of Sahay being to OCEN as to what BHIM app was for UPI.

Now for the consumer, FastLoan is an app providing loans (technically I’m just a conduit to get a loan – but I own that consumer relationship and can cross sell other value added products/ work on margins/ get a commission).

In OCEN architecture parlance, I am what is called a “Loan Service Provider” or an LSP.

Unless the parent entity that owns this LSP also gets an NBFC license and cracks partnerships with banks to co-lend, it is only responsible for providing the interface between the lender and the borrower and is not the actual lender on books. That job still belongs to the banks/ NBFCs with an RBI license.

The entire loan cycle flow, however, is handled by the LSP. From loan origination (which means competition to acquire customers) to underwriting (which comprises of identification, risk assessment & documentation) to facilitating disbursal and finally collection - the efficacy of the loan cycle depends on the way the LSP designs this consumer journey.

Since the building blocks for this are all out in the open and available to anyone who wishes to build such an app, for an LSP to stand out it would require:

1. The best set of customers (quantity + quality). At the end of the day an LSP is but an evolved version of a DSA (Direct Selling Agent - which already several lending apps are) and only if you get access to the best customers (think higher ticket size, more repeat usage, lower chances of non-payment, high collection rates, etc) can you stand out in the market and get the best of point number 2.

2. Partnerships. Some competitive advantages never cease to exist, no matter how open a system might be, right? Here too - different banks will have different Loan Management Systems (LMS) that utilize the same OCEN rails. Cracking those bank partnerships is critical to get the best loan offers on your app. Once you crack that partnership, you need to integrate the bank’s LMS with your system. Similarly, cracking partnerships with Account Aggregators (AA) that provide data is equally important. If you have partnerships with some AAs you can technically build a better flow without the customer having to ever leave your app (explained later).

3. Risk and business rule engines. As an LSP can I utilize various alternative sources of data to make the most accurate risk assessment algorithms? If I can do that, banks would have much greater clarity on the kind of offers bundle they can put out with FastLoan. Therefore building these risk assessment algorithms would be extremely critical in a data abundant future.

4. Value-added services. Offer a sexy looking credit card, provide insurance on top of a car loan, give sellers on your marketplace special loans to advertise their products on your platform- the possibilities are quite endless! Targeting niches therefore might be important for LSPs in a red ocean (which is what open protocols end up doing I think).

5. Lastly, but quite importantly - the in-app customer journey. At the end of the day if there is a lot of friction to your product, if your transactions are failing or if you’re not reminding the customer to pay the loan in time - it’s just a bad journey and will reflect in your account statement. Therefore, it’s very important to add “good experience” on top of “ease of access”.

So let’s say you download the app - we onboard you as a customer showing a simple 3 step process to get a loan (only if it was a 3 step process at your local bank branch, right?).

Create and link your AA and LSP accounts, send data to the bank to get loan offers, and get credit to your account instantly.

It’s that simple! (Only if…)

There’s a lot that goes on than is actually stated while selling the product proposition, so let’s break it down a bit.

Say you are taking a business loan (and not a personal loan).

To start you off, we begin by creating your FastLoan account (an LSP account). To do that a user needs to enter a mobile number and a 15 digit GSTIN number (against which that mobile number was registered). At each step an OTP is sent to the mobile device which is auto-read by the device.

A verification call is made to confirm your GSTIN information and upon that, a unique FastLoan ID is provided to the business entity. This ID is called a Virtual User Address (VUA) which can be shared by FastLoan to a lender. It’s quite analogous to a UPI ID.

Voila! Welcome to FastLoan…

Now, before a loan can be offered, you need to create an account with an Account Aggregator or AA.

What does an AA do? Nilesh Christopher explained it quite aptly in one of his stories for FactorDaily a while back: “Account aggregators can act only as pipes through which data from financial information providers are passed on to users of the information. While requesting data from banks and financial institution, the account aggregators will have read-only access to customer data and will not be able to store, change or process the information.”

“While the technical specifications for such pull and push requests are specified, it is unclear as to which entity will do the job of data aggregation.” - this point still needs more clarity (hence the expected wait of 2 years I guess).

When this gets sorted (🤞), the primary job of an AA will be to pass this data between 3 parties - you as a user, multiple Financial Information Providers (banks/ mutual funds/ GST platform, etc. that hold your information), and lastly the Financial Information User (in our case, the lenders that use the information to give loans).

The image by Sahamati below really is the best description of how an AA works.

As a user, you hold the power to consent what data you allow your AA to access (but not store) and share with the lender (the LSP acts as a conduit to pass this data, but doesn’t directly access it). An LSP however, can top off this data with its own alternative data sources (think SMS access) that helps a lender in making a decision.

The entry point to this very critical flow (you can’t give a loan without getting data from AA) can happen at various instances. You can do it directly on the home screen (like you see we’ve done) or bring that up when a user actually indicates intent to apply for a loan (the latter has the benefit of less friction).

With all data stored in one place (Pandora’s box, right?) it removes any paperwork that might be needed to apply for a loan.

We won’t go into the AA registration flow for the sake of simplicity, but note that if you have a partnership with a registered AA then the user can technically just create/login to one within your app. Otherwise, he/she/they will have to step outside your app to first go and approve the request with the AA.

This is why we mentioned the importance of AA partnerships earlier. So far only a handful of AA operating/ in-principle licenses have been given by the RBI and there’s a lot of debate on how secure these systems are. But these are the ones you need to keep an eye on.

Anyway, now that the data access and origination are sorted, we can move to the lending flow. Note that a user, on downloading the app, could either be someone who is actively looking for a loan or can be someone who just saw the app’s advertisement and downloaded it.

In the case of the latter, we still want to sell them something even if they don’t want a loan. If you’re one such user, you open the Loans section inside your FastLoan app and you see a sexy black credit card by IDFC First Bank with FastLoan co-branding (remember we said partnerships?). We push a business credit card to them. This can be something that doesn’t even use OCEN rails. But we sell this value add service anyway.

Alternatively, if a user IS ACTIVELY looking for a loan for their business (most likely came in as a lead) - that’s where the cash flow based lending model behind OCEN kicks in.

Do you remember we had prompted the user to link her AA account with FastLoan on the home screen and requested her business’ GSTIN number at the time of registration?

All that information becomes useful here on.

The LSP (FastLoan) hits the AA and requests all the invoices that the user might have submitted while filing for GST. These invoices are a good proxy for the health of her business and her ability to repay the loan. When applying for the loan, she is shown all the invoices and she can select the invoices she wishes to submit to lenders to get potential loan offers.

She can also select the total amount of loan she needs and the tenure of the loan she is looking for. All the other information (which otherwise a typical bank branch would have asked such as PAN, address, etc. is submitted by the AA directly to all lenders via an API call - thereby removing all paperwork).

The lenders use this information to make various loan offers. The offers could vary based on the loan amount approved, the interest rate offered, the tenure, and other repayment details.

The user is therefore easily able to view and compare loan offers from various lenders in one place! She doesn’t need to run from one branch to another to make an informed choice.

This entire flow can be represented by this high-level architecture diagram that is available alongside OCEN APIs on iSPIRIT’s GitHub page.

Note: For ease of simplicity in explaining this process we skipped a few parts such as PCR or Public Credit Registry which is an information repository capturing data on loans taken from all kinds of sources including from banks, NBFCs, corporate bonds, External Commercial Borrowing, Inter-Corporate Lending, Masala Bonds, etc. Its purpose is to prevent someone from taking the same loan from 2 different LSPs on the same invoice (De-dupe).

So, from here on, a user can go through the terms and conditions of the selected loan/ talk to a dedicated bank using a call button and finalize a loan with a partner bank/ NBFC. Once the loan is booked, various collection methods get enabled for loan repayment such as NACH and UPI e-mandate, etc.

Honestly, I feel this is a gazillion time an easier process to take a loan than to wait in a poorly ventilated bank branch of a Tier 3 city, waiting for your turn to speak to the branch manager and also maybe offer him a bribe just so that he “passes” your loan application.

An important shift towards cash flow based lending

Now notice something important – the type of loan here is a cash flow based loan and not an asset-based loan where companies borrow money based on the liquidation value of the assets on the borrower’s balance sheet. In asset based loans, banks arrive at a company’s working capital requirements by subtracting the borrower’s current assets and current liabilities.

But micro-enterprises might own very few or sometimes no assets at all. The OCEN framework, with the help of Account Aggregators and GSTIN information, increases the drawing power of small businesses vis a vis that in an asset-based lending model.

This is why at the start of this blog we said that the real problem that OCEN is most likely to solve is the asymmetric access of credit in the country, not just the total availability of credit.

This has been long due. The UK Sinha Committee Report in its recommendations to boost the MSME sector had also suggested this and in fact, the SBI has been pushing Public Sector Banks (which have a 55% share of India’s loan market), to shift to cash flow based lending models. Private sector banks already use this method, but it’s still limited by their ability to gather cash flow data (especially for smaller businesses).

OCEN will hopefully change the status quo. That’s why I like to call OCEN the Oprah Winfrey of banking. Would you agree? If so, don’t forget to forward this email to at least 3 friends! (I’m sure you have 3 friends, help us spread the word please? 🙏)

Share on Whatsapp

You get credit! You get credit!! Everybody gets credit!!!