All-Encompassing Lending Platform for the Poor?

Is that arrogant enough? But what if we could create a generalized digital lending platform that is specifically designed for the needs of the world’s poorest people? Is that remotely possible? What might it look like?

This blog takes a high-level shot at this – not because I think have all the answers (duh!) but in the hope that it will generate some discussion that may contribute a little toward the goal of full financial inclusion. So first, a couple of caveats:

1. We cannot consider credit in isolation from savings, payments and insurance. So a credit platform on its own will not meet needs.
2. Given regulatory, cultural, geographic and political differences from country to country, there are bound to be places where this wouldn’t work completely if at all.
3. The solution should be designed so that it can be built independently of financial institutions, potentially using open platform and protocols, and business rule driven sufficiently to allow heavy adaption in different contexts.

OK, now a few principles:

1. Functions requiring interaction with a person should be designed for simple and secure usage with agents (whether independent, or employed by MNOs, banks, or specialist companies).
2. Delivery of services to customers and agents should be through SMS-based mobile phones, but designed to support smart(er) phones as they become more prevalent over time.
3. Loan products should be designed for the highly flexible needs of the poor, not the convenience of the lender. This implies a parameter-driven, roll-your-own-loan approach that will send shivers down a credit officer’s spine, but could (I believe) still be accomplished safely.
4. It should be possible for an intermediary player, such as an MNO or a digital financial services aggregator, to operate this solution, as well as a financial institution.

Now, what are the parameters that a customer would use to define his own loan requirements? Given the complexity of household financial management practices, and the large numbers of instruments typically in use today, a platform that is to meet all or most of a poor household’s needs would allow them considerable flexibility in designing a loan that meets the challenge of the moment. Some of the parameters would include:

• Amount of loan
• Term of loan (as initially estimated by the customer, but changeable at customer request during the life of the loan with appropriate pricing adjustments)
• Purpose of loan (household, asset purchase, business capital or operations, debt repayment, etc)
• Collateral offered (if any - savings, asset, long-term deposit, etc)
• Disbursement method (cash-out from agent, digital, transfer), payee (such as another lender) and schedule (not necessarily all at once)
• Repayment method (e.g. mobile transfer, cash-in to agent) and schedule (daily, weekly, irregular)
• Loan source type (e.g. Line of Credit draw, P2P lending member, lending institution) – this could be particularly relevant for a non-bank aggregator that includes a peer-to-peer lending service in which friends and family could be enrolled.

At the bottom of this post, you will see a picture of what it might look like conceptually.

There are several components:

1. The Customer Platform, which drives Mobile interaction with the customer through secure SMS or whatever protocols make most sense in the context. This platform controls dialogue between the customer and the provider, and between the customer and the agent. It is primarily responsible for customer experience. It should, of course, be carrier- and device-independent.
2. The Agent Platform, which drives Mobile interaction with the agent, again using UIs and protocols most appropriate to the context. This platform interacts with the Customer Platform and also with the Back Office Platform, and utilizes the shared services such as the Pricing Engine, Documentation Engine, etc). Again, this should be carrier- and device-independent.
3. The Back Office Platform, which supports staff employed by the credit product provider. This supports exception underwriting, servicing, work-out, collateral management, etc, and is functionally not too different from a traditional loan platform, apart from the flexibility of the loan products supported.
4. Calculation Engines, such as the rather complex pricing engine, credit risk, semi-automated collateral valuation, and document generation. These are most likely Web Services or equivalent cross-platform accessible services.
5. The Back Office Platform would be the source for Core Banking Systems - legacy systems of record at the service provider including systems such as credit, deposit accounting, payments, general ledger, profitability, customer MIS, and regulatory analysis and reporting (AML, etc).

Some interesting challenges to be considered would include:

• Pricing strategy and methodology, taking into account all the loan and customer variables – creating a flexible standard pricing model (with parameters for providers to determine desired spreads, cost of funds, etc) might be a good PhD project for somebody.
• Profitability, which is driven by cost structures (particularly minimizing marginal / unit costs to allow volume to drive down average costs) and pricing levels (origination fees, interest rates, renegotiation charges, credit quality, etc)
• Choice of technology (open-source languages, platforms, protocols, etc) for development, deployment, security, privacy, robustness/availability, etc.
• Operational procedures for agents and back office staff, intended to minimize manual effort (and its associated cost and error-proneness)
• Customer service – which could be very expensive particularly if the customer and agent interaction design lacks clarity
• Regulatory requirements for each implementation context (country or region)
• Overall credit and operational risk

This is a pretty significant list of not-yet-worked-out considerations, and there are others of course. I will hopefully publish something later that goes into a lot more depth, and which looks at some of the significant functional challenges in many of the above-described platforms. My premise, though, is that it is at least theoretically possible to build a widely available generalized lending platform that would actually meet the needs of the poor, but will be sufficiently automated to be cost-effective to operate without unacceptably high pricing (whether fee or interest pricing – for many poor households there’s not much of a meaningful distinction anyway).

Pipe dream? Perhaps. But we’ve said that so many times before when people have had ambitious ideas. What do you think?