OCEN: A Conversation

Everything you need to know about the biggest story in Indian fintech this year - the Open Credit Enablement Network

and

Sep 19, 2020

So there’s been a ton of noise about OCEN over the past few months. You’ve probably been bombarded with an onslaught of tweets, whatsapps, blog posts, snapchats (maybe?) about this ‘new paradigm for credit in India’. Here’s what you need to know:

For starters, how the hell do you even pronounce it?

Its pronounced “o-ken”, and it stands for Open Credit Enablement Network.

O-ken you please elaborate further?

……wow, that was horrible.

Anyway, as the name suggests, the idea is to create an ‘open network’ to facilitate the flow of credit. At a glance, this network comprises lenders, borrowers, credit bureaus, underwriters, tech companies and - most importantly - a new class of entity called Loan Service Providers or LSPs.

As a philosophy, OCEN reimagines the lending ecosystem in a manner wherein any service provider that interfaces with customers can now also play the role of credit provider.

In order to do this, OCEN provides a standard set of tools that represent the various components of a typical lending value chain, allowing any app, marketplace, aggregator et al to 'plug in' lending into their current operations.

The reason the network is ‘open’ is because all of the rules that govern the functions of the network are out in the open. OCEN specifies a set of public APIs (programming rules), and any company is free to adopt these APIs to begin participating in the network as a lender or LSP. The way the system is designed, any lender can work with any LSP as long as both parties are using the standard rules prescribed by OCEN.

Whoa, whoa, whoa…can you take a couple of steps back?

To understand the utility of this idea, you need to understand the status quo. Imagine Swiggy decides that it wants to begin offering loans to the restaurants on its platform. This makes perfect sense - by adding lending to its array of features, Swiggy would deepen its loyalty and allure for its restaurant partners. Moreover, adding lending to the app would also help Swiggy generate more direct revenue (in the form of commissions for facilitating these loans) and indirect revenue (if the restaurants had more funding, they could do more business, which ostensibly means more money for Swiggy).

The same logic would probably hold true for a large number of online marketplaces and platforms. Anyway, let us say that Swiggy has decided to launch credit on its platform and has decided to approach Bajaj Finance with the offer of a partnership. Looking at things from the lender’s perspective, tying up with Swiggy would help unlock access to hundreds of thousands of borrowers already present on Swiggy’s platform. Furthermore, Bajaj Finance could ask Swiggy for proprietary data about the borrowers that would aid in the underwriting process. Stuff like average order value, average rating, order patterns, and so on. Low cost distribution channels and richer underwriting data - this partnership already makes sense for Bajaj Finance.

So now that the two parties have decided to team up, they would probably work on defining some commercial and operational responsibilities. Depending on the complexity of the proposed loan product and the nature of these operational and commercial undertakings, this part of the process could take anywhere from a few days to a few months.

Next up, Bajaj Finance and Swiggy would need to integrate their technology systems with one another. Because the two parties don’t know how the other runs their system, this phase of the process usually involves a lot of painful meetings, customizations, and compromises. In short, it is time consuming, costly, and painful.

Even if one party - say Swiggy - publicly announced their own APIs for technical onboarding with lenders, the process might be less opaque and lengthy, but it would still require a lot of duplication of effort if Bajaj Finance wished to also partner up with Zomato. In that case, Bajaj Finance would have to maintain two different tech system integrations with two different loan distribution partners. This problem gets worse and worse the more partners you work with, and the cost and complexity of such an effort can become too much, especially for firms that don’t specialize in tech.

This is the heart of the problem that OCEN solves. If you can create a common language for all these parties to communicate in, you can replace these costly, complex bilateral tech integrations with a single standard. In our example, if Swiggy had built their lending feature using the OCEN rules, they wouldn’t have to change anything in order to integrate technically with any other lender. By the same token, if Bajaj Finance supported the OCEN standard, then they would be able to use the same tech to integrate with Zomato or any other platform using the standard.

In this way, OCEN uses a set of open APIs to create a level playing field for credit. Much like how the Bluetooth standard allows devices from different manufacturers to communicate seamlessly, OCEN will allow LSPs, lenders, and other participants of the credit ecosystem to communicate without the need for customized tech integrations.

Ok that’s...cool? But you didn’t even tell us what an LSP is?

An LSP is an entity who provides the service of facilitating loans for a borrower. So, in the case of our example, the LSP was Swiggy! They are the ones who already have an interface and a prior relationship with the restaurants; by becoming an LSP, they implement APIs that make it easier for lenders like Bajaj Finance to access and finance these restaurants.

Unlike direct selling agents (or DSAs), LSPs are not agents of the lender. Whereas the DSA is charged with going out and finding as many borrowers as possible for the bank/NBFC, LSPs are supposed to be agents of the borrower who help them find the best credit products to suit their needs.

As envisioned in chapter 8 of this RBI report on improving the health of small and medium enterprises, LSPs are supposed to help borrowers decode and navigate the loan offers put forth by lenders. In an ideal world, LSPs will not take a commission from the lender, and will disclose to the borrowers any incentives or conflicts of interest which might affect the way they present different loan offerings.

As the report points out, LSPs should not be confused with lenders. The LSP is the marketplace or platform that helps the lender by opening up its captive pool of users. As we saw in our example, Swiggy or Zomato could be LSPs that help their restaurants (or regular users) get access to credit through the OCEN rails. OCEN APIs help connect Swiggy to a patchwork of lenders that will compete to offer loans to the restaurant partners on Swiggy’s platform, effectively turning Swiggy into a credit marketplace.

In similar fashion, many of your favourite apps and platforms would probably make for a great LSP. If you have reasonable distribution and some reliable, valuable data about borrowers, it probably makes sense to think about becoming an LSP. As you can imagine, there are hundreds of apps that have these assets that can now easily adopt the OCEN standard to begin adding credit products to their platform.

As far as we are aware, many of the country’s top internet companies like Bank Open, OKCredit, ClearTax, Paisabazaar and others are on their way to becoming LSPs.

Sweet! Why is this such a big deal though?

Well, because despite the immense strides we’ve made over the past decade to accelerate financial inclusion in India (think digital identification, more rural bank accounts, sophisticated payment systems etc), the penetration of formal credit is still woefully short of where it should be.

People and businesses should be able to access credit at a fair price and under fair conditions within the right time frame. This is one of the most basic and essential ingredients of a functional economy. It isn’t a stretch to say that we haven’t scratched the surface of our economic potential primarily because our financial protagonists have failed to guide credit into the hands of those who need it most. But to be fair, its not entirely their fault. The numbers just don’t add up.

Banks and traditional NBFCs are constrained by old world methodologies and largely ‘one-size-fits-all’ credit products. This means that in a typical lending value chain, the process of finding and acquiring customers makes up a large chunk of the operating costs. When you add in the costs of document verification, underwriting, and physical collection of repayments, it becomes economically unviable for a bank or NBFC to provide a loan below a certain ‘ticket size’. This effectively leaves out a large chunk of lower income customers and MSMEs from the financial system, forcing them to take their chances with informal credit from loan sharks at exorbitant rates.

But wait, there’s more.

Because lending has traditionally been a balance sheet-based operation built around analysing and collateralising the assets of loan applicants, small businesses that can’t offer the same security often make for riskier customers from a bank’s point of view. This usually results in MSMEs having to agree to higher rates of interest and stricter repayment terms. Additionally, borrowers that need credit the most are usually the ones that can’t offer the same detailed documentation, formal data, or reputational proof that larger enterprise customers are able to provide, thus making for less-than-ideal customers.

So now we have a situation where the banks and NBFCs are happy to meet the larger credit requirements of ‘safer’ enterprise customers. At the other end of the spectrum, you have microfinance institutions and moneylenders catering to the bottom of the pyramid (albeit in an inefficient and expensive manner). And you have a massive ‘Missing Middle’ that doesn’t fit into the framework of existing credit products or processes. This has resulted in an MSME credit gap of $330bn with 89% of MSMEs left without access to formal credit. Not only is this a stain on our economic capabilities, it also represents a massive opportunity for our fintech community to tackle.

Ok that sounds not so good. So how does OCEN actually help solve this problem?

OCEN is an attempt to recognise that in order to truly widen the net of financial inclusion in India, we need to empower the various entities and platforms in our tech ecosystem to play key roles in a reimagined lending value chain (whew that’s a mouthful). OCEN is an acknowledgement that the access points to the formal credit system should exist beyond the walls of just banks and NBFCs.

By standardising the building blocks that make up a typical credit cycle, OCEN ‘activates’ the myriad service providers we use on a day to day basis to become fintech-enabled credit marketplaces.

Think of it like this, the Indian start-up landscape is made up of colourful actors like kirana tech players, food delivery apps, logistics companies, ed tech platforms, Saas providers and more, who already serve the purpose of aggregating users (whether they be businesses or individuals).

If you allow these companies to easily add lending as a feature via standardised OCEN APIs, this means that the cost of customer acquisition for a lender is basically brought down to zero. Moreover, the usage data that is already being captured on these platforms can help add colour to a borrower’s profile to better assess their credit worthiness. This allows for a new modus operandi built around analysing current and future cash flows as opposed to static balance sheet based lending. Add to this the fact that the entire lending process can now be digitised right from customer acquisition, to data collection, to monitoring, to repayment; and suddenly the unit economics of innovation don’t look too shabby.

You have a fertile ground to plant entire species of new credit products that are tailored to a user’s specific requirements, and are available within the course of their routine digital activity. That’s pretty cool.

So to recap, the OCEN protocol offers a number of benefits to its key stakeholders:

For Borrowers:
- they get access to credit products on their favourite apps and within the course of their daily routines
- the lower cost of customer acquisition for lenders should result in a lower interest rate for borrowers
- they can avail of highly customised credit products tailored to their activities and requirements
- their transactional data can be used as a data surrogate to give them access to credit products that may have been previously out of reach
- they can make an informed choice about what products to choose based on the advice of LSPs, who are designed to be agents of the borrowers

For Lenders:
- they can reduce the cost of operations by leveraging the customer pools already aggregated by LSPs
- introducing digitisation across the lending value chain frees them to offer more innovative and personalised products to customers
- they can expand their markets by offering products to customers that may have been too expensive to reach or too difficult to underwrite
- they can use LSPs as natural points for collecting repayments (i.e. they can lock in some portion of incoming cash flows as part of the repayment cycle)
- because LSPs maintain an ongoing relationship with users, they can be used to monitor the activities of borrowers, helping to alert lenders in case of any red flags

For Loan Service Providers:
- they automatically earn the Kunal Shah Fintech Award for providing lending-as-a-feature
- they can improve their Net Promoter Score by more holistically solving the needs of their customers
- they increase the stickiness of their apps by providing ‘embedded finance’ within their existing product or service flows
- they gain easy access to a new revenue stream whilst simultaneously enhancing the liquidity and economic potential of their users

Wait a minute, a completely digitised lending process? How did that happen? Can you elaborate on that?

Sure. Its important to note here that India has taken a unique approach to economic development over the past decade by building public digital infrastructure as a route to financial inclusion. This set of building blocks (called India Stack) provides the components needed to enable digital services that are presence-less, cashless, paper-less and built around user consent. Each of these public tools can now offer a digitised cog in a reimagined lending machine.

The first step of the lending process is originations. This step is digitized because through the OCEN framework, the LSP offers a digital interface for borrowers to engage with lenders. Therefore, the lead generation process for the lenders is completely digital.

Second comes underwriting. The lenders need some data upon which they can base their analysis of the borrower. Some of this data comes from the LSP through the OCEN APIs. Other data can be fetched electronically from credit bureaus and identity verification utilities such as eKYC and NSDL (for PAN verification). The rest of the data, such as bank statements and GST invoices, can be pulled through a new kind of entity called an Account Aggregator (AA). We will dig a bit deeper into AAs in a second, but for the time being just stay with us.

After the underwriting process is complete, the lender needs to offer a loan and the borrower needs to accept it. This can also be done electronically on the LSP’s interface through the OCEN APIs. Once a loan offer has been selected, the borrower needs to accept and sign the loan documents - at this point, the eSign digital utility can be used to generate a legally-admissible signed loan document.

Before the funds can be disbursed, the borrower would need to select and commit to a repayment schedule. On this front, the borrower could set up auto-repayment using a credit card, electronic NACH mandate, or UPI e-mandate. The OCEN APIs also allow the LSP to forward a lender’s repayment link to the borrower for direct payment execution.

In addition to establishing a repayment schedule, the lender might also wish to secure visibility into the borrower’s future finances. Doing so would help the lender monitor the status of their loan and take early action should they discover some red flags or warning signals in the borrower’s behaviour. This, too, could be achieved digitally - the lender would merely need to take the borrower’s consent to monitor their bank account, and the Account Aggregator would ensure that the lender gets the required information.

As a final step, the lender could disburse funds to the borrower using online payment methods such as UPI or IMPS. In this way, the entire lending flow could be conducted digitally using low-cost public infrastructure:

Originations - LSP

KYC - eKYC, PAN, Account Aggregator

Underwriting - LSP, Account Aggregator

Documentation - eSIGN

Collections - LSP, eNACH, credit card, UPI e-mandate

Monitoring - Account Aggregator

Disbursals - NEFT, IMPS, RTGS, UPI

Back up a second. Account Aggregators? That’s a whole other thing right? Seems like its raining paradigms in India. What’s the difference between AA and OCEN? And how does AA fit in here?

That is a very important question. Account Aggregators are a fascinating and exciting topic that warrant a much deeper discussion. We have actually written extensively about them before, but here is a summary for those who are short on time.

The Account Aggregator framework is a new model for data governance and data sharing in India. Account Aggregators (AA) are a novel type of NBFC tasked with performing the role of data fiduciaries, where their mission is to facilitate the transfer of user data from the entities that house this data to the entities that want to use this data, only on obtaining user consent.

The market architecture looks like this:

You have Financial Information Providers (FIPs) on one end, Account Aggregators as ‘traffic cops’ for this data in the middle, and Financial Information Users (FIUs) at the other end. This is a landmark moment for data protection and empowerment in India as these AAs will provide users (and entities) with an easy way to access and share their own data.

Before AAs, lenders had no simple way of digitally ingesting your bank data - they had to either download your bank statements as PDFs and parse through them, or they had to perform optical character recognition on an image of your bank statement, or they had to use a technique called screen scraping to get the data out of your online banking profile. All three of these methods required the lenders to maintain multiple different templates for handling and transforming your data. Thanks to the standardized, machine-readable data provided by AAs, all this complexity is gone - ingesting and processing borrower data has become much cheaper, quicker, and easier than ever before.

In addition to this benefit enjoyed by FIUs, AAs also carry many benefits for data owners themselves. Chief amongst these is the ability to manage one’s data with granular control. Using an AA, an individual or business can choose exactly which data to share, with whom, for how long, and under what conditions. For example, when using a traditional method like a PDF upload to share a bank statement with an embassy to show proof of funds, a user would have no way of hiding a sensitive transaction like a visit to an abortion clinic. In contrast, the same user could use an AA to pick and choose the transactions to share, thereby retaining greater agency and privacy over their own data.

As we said before, the features and ramifications of AAs are significant enough to warrant their own blog post, but in the context of OCEN, what we need to know is that AAs serve merely as enablers or supporting utilities. They are involved in the credit flow to the extent that they capture the borrower’s consent to share data from the borrower’s data providers to the network of lenders. In this context, the borrower’s data providers would be the banks, the GST system, the credit bureaus, or indeed the LSPs themselves. After all, the LSPs would need to get the borrower’s consent to share data with a lender, and as a designated consent collecting entity, the AA is perfectly suited for that task.

For example:
- Say a restaurant owner on Swiggy wanted to obtain a loan using the OCEN-enabled application flow. The banks and NBFCs that could potentially provide her with a loan will need to analyse various data points based on which they can make a decision about whether to lend to her or not.
- Although Swiggy could help the restaurant owner offer up data points like total orders per day, popularity vs other players in the same category, number of orders in a particular post code etc, the lenders might also want access to other official sources of data, such as her bank balance at the end of the day or how many invoices she uploads to the GST portal.
- This ‘request for data’ forms part of the application process for a loan for any restaurant owner using the Swiggy app to avail of credit.
- So how does she actually perform this task? Using an Account Aggregator app, the restaurant owner can consent to her bank providing this data to the lenders and to the GSTN sharing her official GST invoice data with them, in a standardised machine readable format that can be easily digested by the lender’s underwriting model.
- The transfer of this data will be facilitated by the AA application with which she has a registered profile (just like a payment app) and this process will be neatly embedded within the overall application flow.

So long story short, the LSP is the entity that provides the bridge between the borrower and the lenders. Through the OCEN APIs, the LSPs facilitate the entire lending process for the borrower from discovering loan products, to selecting the right loan, to preparing the data, to completing documentation, setting up re-payment schedules, and managing the connection with the lender post-disbursal.

For many of these tasks, the OCEN APIs require the LSP to redirect the borrower to a different stakeholder. For instance, to handle repayments, the LSP can redirect the borrower to a payment provider selected by the lender. Likewise, when it comes to giving consent to share data, the LSP can redirect the borrower to the AA. Upon successful issuance of the consent, the LSP would be alerted, the lenders would receive the data via the borrower’s AA, and the lending flow would continue.

This is the difference between the LSP and the AA. Whereas the LSP is a specific kind of institution that provides a bridge between lenders and borrowers on the OCEN network, the AA provides the service of collecting consent and facilitating data flows between parties for many different kinds of use cases, not just lending and not just within OCEN.

Is there room for more participants in this newfangled credit landscape?

Ain’t no party like an Indian fintech party (nobody actually says this). Not only is there room for existing participants, but OCEN has opened the door for new entities to play a vital role across the OCEN-enabled lending value chain.

If you’re a start up, a fintech player, a lender, or an observer, you might be confused about where you fit in or where you can best be useful. We’ve highlighted some ways you can get involved.

LSPs: As we said, any platform which has an existing user base along with some commercially or financially relevant user data has a decent value proposition to be an LSP.

Lenders: Because lending is a highly regulated industry, the number of companies who could engage in lending through OCEN is limited. Having said that, entities who do possess the requisite licenses to lend would probably find that the introduction of OCEN will herald a new wave of creative and interesting financial products. There is likely to be a lot of opportunity in this field.
Payment Service Providers (PSPs): PSPs have an interesting role to play at both ends of the lending process - providing instruments and infrastructure for controlled disbursal, and then for the timely collections of repayments.

Credit Bureaus: In addition to their usual role providing information on a borrower’s previous credit history, credit bureaus might have a new role to play in the lending landscape of the future. Since OCEN and other projects like the Account Aggregator framework help enable shorter-term loan products predicated against specific invoices, receivables, or cash flows, there will likely be a need for a new kind of liabilities registry. In contrast to the traditional credit bureau registry which takes 1-2 months to reflect a new liability, the new registry would need to keep a real-time check on borrower indebtedness to help lenders better manage risk. This functionality might eventually be captured by RBI’s planned Public Credit Registry, but in the interim there are plans to set up a Common Pledge Registry to help lenders on OCEN keep track of which borrowers have taken a loan against which assets.

Underwriting Modellers (UMs)/ Derived Data Providers (DDPs): A lot of the data within the OCEN framework might be arcane and hard to decipher. For example, making sense of a borrower’s ride history on Uber would probably be an inconvenient and confusing task for lenders who specialize in fundraising and risk management. On the other hand, this might present a great opportunity for startups who excel at data science or on-ground operations. These startups could combine their on-ground learnings with the LSP data extracted through OCEN to glean relevant insights for their lender partners to consider in the underwriting process. These firms could also provide their own analyses and credit scores, even going so far as to participate in the risk with their lender partners. This could be a good opportunity for new firms or existing fintechs who work in the ‘off-book’ or ‘co-lending’ model.

Tech Service Providers (TSPs): As is the case with any new tech ecosystem, there will be a huge opportunity for TSPs to come in and provide software solutions to ease the transition to the new system. In a space as new and empty as OCEN, there is a massive white-space for startups to come and build products and offer services. One can imagine a system wherein a TSP offers an LSP a white-labelled solution to come aboard the OCEN system quickly and effectively. This could include offering customizable front-end interfaces for borrowers, building and maintaining all the APIs needed to interact with lenders, AAs, and others, or managing the data transformations that might be necessary for an LSP to conduct before they can start sending data out to lenders.

Ok big shot. I saw Star Wars too. All of this stuff sounds like it belongs in a faraway land deep into the future. So where are we at?

We’re not that far away actually. The ecosystem has begun playing around with potential LSP use cases. CredAll has been helping a variety of potential LSPs to build out their business cases. Tech companies are working on the ideal flows to introduce credit into their existing products and services. There are a number of different types of companies who are now working around integrating OCEN APIs including:
- Kirana tech apps
- Ed tech platforms
- Invoicing apps
- Neobanks
- Accounting, tax, and legal service co’s
- Existing fintech co’s
- and everyone in between

TSPs like Setu and Apollo Finvest have already published APIs that make it easy for both lenders and LSPs to integrate with OCEN. Furthermore, there are a number of lenders and LSPs already onboarding to the network, keen to explore if OCEN represents a significant step forward or not.

Just like BHIM was the first reference implementation for UPI, the first reference apps for OCEN will be the Sahay GST and Sahay GeM apps. These apps will provide businesses on the GST network and the Government eMarketplace (GeM) with a way to easily apply for credit using their GST invoices and transaction history as data surrogates to obtain loan offers from connected lenders.

Like BHIM UPI, the idea for these apps is not to corner the market and turn a profit, but rather to inspire the private sector by illustrating how these moving parts in OCEN all come together. We’re going to be doing a deep dive on both of these in our next piece - make sure you subscribe so you don’t miss it!

If you’re interested in participating as a lender, LSP, TSP or everything in between, drop an email to community@ispirt.in and follow CredAll to get updates on the OCEN ecosystem.

I presume there are a bunch of questions still to be answered. Can we do like a rapid fire type of thing?

Sure.

Q) Who, like, owns all of this stuff?

Great question. While no single organisation ‘owns’ OCEN (it is an open protocol created as a public good) there is a non-profit organisation named CredAll whose role is to function as ‘a collective of lending ecosystem players to drive cash flowbased lending’.

This effectively means that CredAll’s responsibility is to ensure the success of the entire ecosystem, and not of any single player. It will have a role to play in areas like stakeholder education; publishing guidelines and principles; helping to connect TSPs with lenders and LSPs; helping LSPs create their business cases; and empanelling certification agencies who want to help ensure the sanctity and interoperability of the system.

At the moment the OCEN APIs can be publicly accessed via the iSpirt Github page.

Q) What happens to the existing model of bilateral partnerships between startups and lenders?

As we mentioned earlier, its been fairly common for start ups and other service providers to set up bilateral partnerships and integrations with banks and NBFCs to provide loans to their users, albeit in a much costlier, more labour intensive and more time consuming manner. OCEN is designed to make these partnerships easy to set up and to open the doors to innovation throughout the process flow.

It remains to be seen which route market players eventually end up taking. To draw a parallel, India was a land of mobile wallets in the first half of the last decade, and these companies had to grapple with a similar decision when UPI was launched. Because UPI made digital payments easy and interoperable, existing wallet players had to decide whether to stick to their guns, or switch to UPI completely, or (like PayTM) offer both as a hybrid solution.

We think the latter, hybrid approach to partnerships is the likeliest outcome in the short term while market players familiarise themselves with OCEN.

Q) How can one become an LSP?

I’ll leave this one to the CredAll checklist:

Engage with published OCEN related resources (technical and business)
Carry out an LSP self-assessment by mapping borrower persona and product types
Engage with OCEN API sandboxes as they get released and design product experience
Implement OCEN APIs and undergo light API certification by CredAll empanelled agency
‘Go-live’ facilitated through CredAll to connect with OCEN certified lenders

Q) How will LSP’s make money?

There is some existing thinking around this but it will be interesting to see how this evolves as market participants rejig their models to fit an OCEN-enabled world. What makes LSPs unique (as opposed to DSAs or BCs) is that they are ‘agents of the borrowers’ as opposed to sales vehicles for the lenders so it might not be as simple as charging a fee for lead generation.

So we could see situations where LSPs charge borrowers an advisory fee for helping to select the right loan product. LSPs could also incorporate some form of credit SaaS into their product offerings as a fully formed feature (eg: helping borrowers to improve their credit score). The credit offering itself could be part of a value added or premium offering in their apps.

They could also play alternative roles as DDPs or UMs, and can charge a fee for those services. The parent entity of an LSP could even have a lending entity under its umbrella intended to work in tandem. The point is, this is fresh ground. And if you have any ideas, we’d love to hear em!

Q) What is the regulatory scenario around all this?

The idea is for LSPs to be lightly certified components within the financial system so as to not overburden service providers with excessive regulatory baggage. They will undergo a ‘light certification by a CredAll empanelled certification agency to ensure tight integration with APIs that ensure seamless customer experience and security.’

Q) Do lenders actually trust the data on LSP apps?

Again, this is something that will probably evolve as we learn more about the various moving parts. It is unlikely to expect lenders to immediately bank on the data that is being captured on existing platforms and apps. However, the work of DDPs and Underwriting Modellers could help to package this in a way that genuinely improves the underwriting capabilities of banks and NBFCs and creates strong lender trust over time.

If you also reconcile this new LSP-given data with official sources of data that are pulled in via an Account Aggregator, then the picture looks much more compelling. This is another one to add to the ‘wait and see’ bucket.

Q) What happens to existing fintech marketplaces and encumbents?

Existing fintech marketplaces can make use of OCEN to make their own integrations easier. One one hand platforms can make use of the standardised protocol to add more lenders to their roster of partnerships, and expand their portfolio of products on the other. The idea is to make the infrastructural cost and maintenance of these partnerships much easier to palate. Therefore, incumbents can leverage their existing domain knowledge to play a number of new roles in an OCEN-enabled value chain.

Q) As an investor or a fintech, what are some of the big trends that one should watch out for?

This is an interesting one - a system with this kind of ambition is likely to create many significant ramifications if it takes off. On the face of it, the biggest impact is on existing loan marketplaces and lending apps.

If LSPs can enable low-cost loan distribution at the right place and the right time for the borrower’s specific context, then would there still be a need for general-purpose loan marketplaces? If your business model relies on capturing users today and monetizing them tomorrow through lending, is the foundation of your business still intact if any app can now easily add lending as a service?

Some commentators might say no, but it seems improbable that established industry players will disappear overnight. After all, these players have spent lots of time understanding their customers and finding ways to package data in a way palatable for lenders.

It will be incumbent on LSPs and the new breed of loan providers to show that they can do the same thing - and in the time it takes them to do so, the incumbents probably will have adapted and evolved. Moreover, companies which acquire users today to monetize them tomorrow through lending are still providing some value proposition today. That could be digitized bookkeeping, accounting, wealth management, or any other service. As long as that service still holds value for customers and yields some robust data for the company, the fundamentals of the business are not just intact, but bolstered by the introduction of a credit coordination technology like OCEN.

In addition to the first-order effects of increasing the availability and affordability of funds for borrowers, decreasing the CAC and improving data for lenders, and augmenting the platform stickiness of LSPs, OCEN is likely to have many second-order effects on the digital lending industry. Perhaps this will result in a new breed of nimble, risk-tolerant lenders. Maybe it will set the groundwork for interesting P2P lending opportunities. Its too early to predict anything with certainty, but it will surely be an interesting space to watch out for. We’re going to be doing a deep dive on the VC case for OCEN, make sure you subscribe so you don’t miss it.