The Long Road Ahead for OCEN (#65)
While OCEN protocol is a step in the right direction, it may struggle to fulfil its vision for financial inclusion
Welcome to the 65th issue of Unit Economics. In this article, I wear a critique’s hat to assess the road ahead for the much admired Open Credit Enablement Network (OCEN). Dive in!
Bank-credit-to-GDP is a strong indicator of the degree of financial inclusion in an economy. Theory suggests that a healthy economy would have it at 100% or more. The data corroborates the theory, with most of the first-world countries in the three-digit range.
For India, however, the number hovers depressingly within 56-60% in 2023. Could this signal low demand for credit? Maybe the retail customers & corporates fear touching credit, or perhaps they find the economy unstable to the extent that they would not risk their livelihoods with compounding debts.
A good amount of evidence debunks this low-demand hypothesis. A report from International Finance Corporation (IFC) this year, for instance, puts the addressable market demand for credit in India at ₹37 trillion, of which ~₹26 trillion or 70%(!) goes unaddressed.
With high unmet demand, the fingers naturally point to a supply-side weakness - on the failure of NBFCs, commercial banks, regional rural banks, and urban cooperative banks to serve credit needs. But we will notice that this is hardly on account of incompetence or will.
We understand that lending is a balance-sheet-led business, where lenders must access formal and detailed documentation to (a) verify borrowers, (b) assess their creditworthiness, and (c) if required, secure collaterals before sanctioning a loan. The surgical nature of assessment is forced by the cash-intensive and it-can-go-downhill-very-quickly reality of lending, which brings up serious systemic hurdles to shore up credit supply. For instance,
A major section of the informal economy lacks access to the required formal documentation, incl. for income, employment, and collaterals. Without the ability to sufficiently verify or assess creditworthiness, the hands of the lenders are tied. This ends up excluding the delivery of credit to a good proportion of addressable audiences.
To compound the challenges, the human-heavy nature of identity & address verification and physical repayment collections makes the operational cost of lending business too high to serve small tickets & thousands of pin codes – which further neglects a large portion of the audience that is either (a) too costly to access and serve, or (b) has low-revenue potential.
Even if we were to magically solve the data availability and high operational costs, the regulated entities would need time to build up deposit reserves to consider immediately scaling up their loan books.
Each of these suggests a long, structural gap in delivering credit to the long queue. Which brings us to OCEN (/ˈo-ken/).
In many water-cooler conversations, OCEN, or Open Credit Enablement Network, has been granted the responsibility of bridging this financial inclusion gap.
But before we poke at the possibility, how does OCEN work?
OCEN was launched as part of IndiaStack in July, 2020.
Rewind: IndiaStack, as is popular, operates on a principle of establishing open networks, i.e. a set of open-source and standardised APIs, to level the playing field for all members of a digital eco-system. The promise of IndiaStack has been fulfilled well through the now-primitive open networks for UPI, BharatPay, eKYC, DigiLocker, FASTag, and GSTN, among others – all combining to deliver value to hundreds of millions already.
In the same spirit, OCEN attempts to create a rulebook for credit, which would codify a set of open standards across the entire lending value chain. The objective is to define a standard API spec that would make partnering with a lender more seamless and would allow any digital service provider, imagine an Uber, to act as Lending Service Provider (LSPs) to provide credit to their customers.
To understand the incremental value of doing so, observe a usual lending life cycle today:
Step 1: The LSP defines its product proposition, including expected credit type, frequency of drawdowns, average ticket size, and a few other metrics. [Takes a few days to a few weeks]
Step 2: The lender, who agrees to deliver on the proposition, then performs a Data Room Exercise (DRE) with the LSP to understand the quality of the customer base, triggering discussions of the provision of alternative data to underwrite – and producing an output of expected approval rate and credit offers. An LSP may repeat this exercise with multiple lenders before selecting the final partner. [Takes a few weeks to over a month]
Step 3: Parallely, the teams get into integration discussions, evaluating closely each part of the lending journey: offer selection & acceptance, risk and fraud checks, alternate modes of KYC, enhanced due diligence, mandate setup, loan agreement signature and disbursal, repayments and collections, and other subsequent parts that come along with repeat loans. The lack of industry-standard on the journey and APIs leads to different interpretations and brings about tons of back and forth before the product can be rolled out. [Takes a few months]
Step 4: Even after the launch, the lender closely monitors the portfolio performance with the LSP, and takes calls to optimise rules, journey, collections, etc. to reach a stable, comfortable state that can allow ramping up. [Takes a few months]
Notice that a generic description of a lending partnership involves multiple hoops and uncertainties. These overheads are sufficient for many digital native businesses, who do not have lending at their core, to be cynical of entering the business of lending – despite the obvious value it may offer to their customers.
This is where OCEN’s model attempts to lighten the burden with a standardised open network. The model introduces a protocol for Technical Service Providers (TSP) to follow, who bear the burden of integration (step 3) with the lenders by building a common-language onboarding & repayment stack, which may then be replicated across multiple lenders.
To visualise, think of a standard API contract as highlighted below.
For the LSPs, this promises to substantially reduce their burden – as they may simply approach a TSP, understand their existing lending partners, integrate using the TSP-offered API stack, and parallely close an agreement with a lender (or multiple) within the existing TSP scope. Shortening the long poles of partner selection & integration.
Quite promising. Now, let’s tie this promise with the bigger picture.
“India needs to go that extra mile in offering credit to the most deserving, smallest businesses and individuals. With most credit directed to large companies in large volumes, smaller companies and micro enterprises are left in the lurch with little or no access to credit at all which is a huge concern for the next growth phase of the industry” said Nandan Nilekani in Global FinTech Festival, 2020.
The above narrative positions the promise of OCEN as once such wherein the protocol would become for MSMEs or individuals, what Payment Aggregators is for the merchants, i.e., it would unlock access to institutions and instruments that were otherwise limited to a small cohort of large, privileged businesses.
Observing the space closely over a couple of years, I imagine the road to acceptance would be more challenging for the OCEN protocol. Let me explain.
Access to partners helps, but the unserved need approvals
In usual circumstances (as suggested in Step 2 above), a lender would carefully assess the customer base of its partner – and to optimise for approval rates and ticket sizes, they would seek relevant alternative data to strengthen their underwriting policy at a partner-level. This is how a lender, who would usually only look at existing-to-credit customers, would seek comfort in opening its doors to those un- or underserved.
But unlike a payments service, where a payment aggregator integration directly correlates to high adoption and distribution via merchants / TPAPs – a plug-and-play lending service, while making the integration easier, works opposite to broaden the gap between the lender and the customer-facing LSP. For instance,
With the envisaged model, a lender is expected to have less face time with the LSP. This is great for LSPs, especially those smaller in size, who desire a fast go-to-market and limited back-and-forth on business or product.
But for the lender – it introduces higher capital risk, as they are farther from the LSP, and consequently, from the customer base they will have to underwrite.
This would mean that unless an LSP’s business arm is closely tied to the lender and the LSP has a scale sufficient to command prioritisation – the lender would proceed with caution.
Second-order effect: lenders are unlikely to (a) consume relevant alternative data from the LSP, and (b) optimise their risk policy as per the customer base of LSP, eventually resulting in low approval rates.
An expected outcome of the arrangement: a majority of the MSMEs or individuals approved for credit would be those with pre-existing credit history.
Assuming the goal of OCEN as one that delivers the “extra mile in offering credit to the most deserving, smallest businesses and individuals”, the above argument pokes some gaps in the extent to which OCEN may prove effective in its goal.
Which pushes us to ask further questions.
Who would benefit from OCEN?
There is little doubt that the OCEN protocol should break the inertia for thousands of merchants to consider lending as an add-on service, and this would particularly attract merchants that expect higher customer engagement due to the add-on.
Naturally, with the popularity of checkout EMIs, an extension of OCEN would be to serve higher convenience at the checkout by offering customers credit at the point-of-sale. The approach for the on-ground pitches from the TSPs falls in line with our hypothesis.
However, with the TSPs operating on OCEN protocol directly competing with the existing EMI options that merchant aggregators offer - the extent of value addition is not as immediate or significant as it would seem.
Even for lenders, generating demand for credit is rarely top of mind, rather the questions they ask are around the management of cost of capital and portfolio performance. With the OCEN protocol championed by the TSPs, lenders would benefit from the lower cost of partner acquisition and the standard approach to integration – with the TSPs helping in both functions. However, the criticality that lenders associate with TSPs would be directly proportional to the proportion of large clients it brings to them.
Which brings us to the next question.
Would the limitations of low approval rates be mitigated by larger-sized LSPs, given the higher business prioritisation lenders would allow for them? Also, will these merchants warm to TSPs operating on OCEN protocol?
For the lenders, access to a large partner would naturally bring their attention to the goal of optimising the underwriting policy & customer journey, in hope for approval rates, which would otherwise be absent for smaller merchants. This is a signal that the uber goal of financial inclusion via OCEN protocol may be best achieved by acquiring large businesses.
Saying that, depending on the protocol may be a tougher sell to the prominent, large merchants. For instance, for a Swiggy or an Uber, a lending play would be as much about long-term strategic gains as it would be about offering the function to its customers. Unless a lender strongly positions their integration via the TSP, there is a strong argument to be made for merchants to go direct with a single partner, as it would offer them (a) higher control of the experience, (b) more flexibility in adding new lenders, (c) stronger commercials, and (d) experience of building a lending stack that would come useful if the merchant decides to operate a financial services arm of its own.
As I see it, if TSPs were to act as a Razorpay for lending, i.e., an aggregator of lenders, the proposition would be strongest for a checkout financing play. However, for a large merchant, there would remain good merit in going direct to the bank. Instead, if the TSPs were to act as primary technology partners of the dedicated banks or NBFCs – à la M2P, Zeta, and Infosys – the positioning would likely draw more conviction for the large merchants.
Final few thoughts…
The adoption of the OCEN protocol as an industry standard would be closely tied to the benefits that accrue to both LSPs and lenders in moving away from the status quo. More importantly, the push to accept the TSPs will have to be largely led by the lenders, who may stand to gain by outsourcing acquisition and integration support to such TSPs.
As I assess it today, the last mile appears longer for OCEN than it did for its predecessors under IndiaStack, given that the application of protocol neither truly (a) introduces a solution that already does not exist with the banks or NBFCs (as DigiLocker or FASTag did), and (b) neither does it resolve the strategic concerns of the regulated entities (portfolio performance or cost of funds) or for merchants (approval rates). Unless such concerns are resolved with sufficient increment, I fear that the value of OCEN would largely be captured by those existing-to-credit via the checkout financing play – and we may fall short of its vision around financial inclusion.
However, despite the outcome, defining a protocol around the lending value chain does help guide the new lenders and LSPs, who would now have benchmarks to measure themselves against, a step that – along with the other recent guidelines from the RBI - promises a more matured state for lending eco-system. Another area that will need more squinted eyes. Until next time!
If you have any views or feedback to share on the topic, feel free to add a response below or to share your thoughts with me over Linkedin. In case you feel your friends or family would be interested in reading about payments, feel free to share the blog with them as well. See you in a few weeks!