API economics in the digital lend game

The total value of India’s digital lending market is estimated to be more than USD 1 trillion over the next five years. To ensure they grab a share of this market, most banks and NBFCs are digitizing their systems.

However, one important aspect of the digital transformation journey which is often overlooked is the platform thinking while designing and developing the system.

Digital transformation morphs the industry from a vertically integrated architecture to a stack-based architecture. This opens up a huge opportunity for all entities to participate in different stack layers and not restrict themselves to the one traditionally they belonged to. In order to interact across the stacks, the lending system should work like a platform exposing Application Program Interface (APIs) to stacks above and below.

In such a connected system architecture, how does one determine the cost of usage of these APIs? Additionally, how does one reduce/optimize these costs? These are the two open questions before any business leader.

APIs allow systems to connect to other systems and share data bi-directionally. There are different protocols for API. However, the most commonly agreed and used in the web-based systems are the RESTful protocols. Most systems use these APIs for communicating in internal and external environments across the different industry stacks.

When the APIs are inherent in the systems, with proper design and incremental effort these can be standardized and exposed to external entities like lead sharing partners. Designing includes the touchpoints of systems and data points needed to run. For example, in a web-based lending system, a complete user journey for lending runs from a user providing data (Personal, and KYC) to sanction. While a short partner journey can include sharing already existing KYC details and just processing the rest of the journey to sanction. In the former, the user will be asked to key in Personal details and KYC details.

However, in the latter, if the partner possesses the personal details, then these details are passed to the lending system through an API and the user will only key-in KYC details. In such cases, where the partner possesses both personal and KYC details and passes them through an API, the user does not need to key-in those details. Mostly, the user will not be aware of when his details are passed to a lending system, however, he will directly see the sanctioned loan. With this design, an application built to run as a standalone lending system to process loans for online customers can also now process leads passed from partners.

The partners can be now grouped on the basis of the touchpoints in the journey, the quantum of data being passed and the veracity of the data. The lead sharing costs can be defined based on the three metrics. For a partner who shares just the customer communication details, and lets the user go through the journey on the lending system keying-in his details, should be charged the highest. A partner who runs the journey on a partner’s platform and comes to the lending system only for calculating the loan pricing should be charged the least. This arises from both the business and technology cost rationale. From a business cost perspective, a lead with minimal data has low probability of closure, seeks time from sales teams to convert to closure and additional effort for operations to verify/validate. The same applies to non-validated data as well. From a technology cost perspective, an early-stage lead takes more computational power, digital footprint and network bandwidth.

Another important factor is the standardization. For any lending platform, once the journey touchpoints and APIs are published and consumed by the partners in a specific format, there can be a leverage of economies of scale. However, customizations either on the touchpoints, data shared or on the structure of APIs will lead to the increased development effort, computational power and digital footprint – overall leading to increased costs.

In summary, API costs are a function of the standardization, touchpoints, quantum of data and veracity of data. Based on these parameters the partner pricing tiers can be evolved.

About the author

Subhash Kasturi, VP, Kuliza Technologies, an organization dedicated to transforming financial enterprises with a low-code platform enabling digital process automation, integrated ecosystem and operational intelligence