Software interoperability can give lending a big fillip

A while back I wrote about John Philip Sousa and his opposition to Thomas Edison’s invention—recorded music. The point I made in that article was that Sousa’s angst with the phonograph was not an isolated incident. Such feelings have re-surfaced time and again, every time the music industry faced some new disruption—when tapes replaced vinyl records; when MP3s replaced CDs; and now when streaming music is threatening to upend the industry yet again.

Change of this sort is inevitable. Joseph Schumpeter called it “creative destruction”—the process of industrial mutation that revolutionizes the economic structure from within, destroying the old and replacing it with the new. Dynamic economies need to constantly renew and re-invigorate themselves, and creative destruction is how they do so.

In the early days of the internet, when technology systems were a lot more interoperable, creative destruction was the norm rather than the exception. No company, no matter how large, could ever claim to be too big to be disrupted by the next big idea. Network effects were not an impediment but an incentive to engage in creative destruction; and since all systems were interoperable, user lock-ins were unheard of.

Today, things couldn’t be more different. Technology platforms are behemoths with more users than the populations of most small countries. At this scale, not only do they not encourage interoperability, they work hard to make it practically impossible to achieve.

Cory Doctorow, a blogger and science fiction author, believes that what we really need today is adversarial interoperability. He wants new technologies to be able to work with existing systems even if the owners of those incumbent systems don’t approve of it.

This sort of interoperability has been an integral part of the life history of most big tech companies. Apple, for example, ensured that documents created on Microsoft’s Office suite could also be viewed within the Mac environment, and committed itself to making sure that they continued to work even after each Microsoft upgrade. Facebook made sure that the MySpace users it was looking to entice away could easily port their posts and photographs onto the new service. Similar examples abound all over the tech space.

But even though tech companies made use of interoperability to become what they are today, they now seem eager to ensure that they do not fall victim to it themselves. Accordingly, much effort has been invested into ensuring that attempts at interoperating with their platforms without permission are dealt with swiftly and decisively. This is why tech companies aggressively discourage the use of unauthorized spares and crack down heavily on unauthorized service centres. It is the reason behind legislative amendments such as the anti-circumvention provisions in copyright law, which were designed to blunt the ability of new businesses to disrupt existing technologies.

We need to make it possible for new technologies to once again interoperate with incumbent platforms without the fear of prosecution. This is what has allowed the tech industry to develop uptill this point, and what is necessary to ensure that it continues to develop well into the future.

Over the past few months, I’ve had an opportunity to work on some of the practical implementations of India’s new Open Credit Enablement Network Specification (OCEN). I have been struck by the way in which these principles foster the sort of interoperability that is so desperately needed in the tech sector today.

The bold ambition of OCEN is to fix India’s broken credit market infrastructure. The solution it proposes calls for unbundling the entire loan ecosystem and then atomizing it down to its constituent parts. This process will ultimately give rise to multiple specialized entities that are each individually responsible for performing each of the many sub-tasks that go into a lending product. Some entities will focus on sourcing and distribution, while others will carry out identity verification, underwriting, capital arrangement, cash entrapment and a host of other functions. For all these entities, OCEN specifications will act as the common binding language that ties the different functions they perform into a single coherent user experience.

At scale, OCEN is likely to generate a profusion of products. There is nothing like taking an entire ecosystem apart to get you to realize that there are many other ways in which it could be put back together again—more than you ever thought possible.

But perhaps more significantly, by atomizing loan services in this fashion, we will create an army of micro-service providers and give each of them the opportunity to develop a high degree of specialization in a narrow and highly-focused skill. Once we achieve a critical mass of micro-skills, we will be able to re-order the service stack itself, giving rise to dozens of new and innovative products that offer new and more efficient ways of getting things done.

For OCEN to work as envisioned, each constituent element must be capable of a radical degree of interoperations with every other. But by enabling that level of software interaction, we would have brought back some of the magic that powered the engines of technology in its infancy.

Rahul Matthan is a partner at Trilegal and also has a podcast by the name Ex Machina. His Twitter handle is @matthan