This is the email that birthed Open Banking Nigeria. Sent just 2 minutes to midnight on June 1, 2017. Sent to those unfortunate to be my friends and so, are subjected to never-ending streams of half-baked ideas and utter madness.
It’s a very long read, so be warned!
****************************************
Good evening everyone,
At one time or the other, we all heard about how payments would be the next big deal. We have heard of big data, APIs, yeti, abominable snowman and all the rest. Unfortunately, many ideas, companies, and committees have been long on intentions but short on execution.
All of us in this email thread know what APIs can do and how payments can transform the lives of our customers, the fortunes of our companies and improve trade and transactions in the country.
However, things are not the way they should be: APIs are hard to get; tough to implement and even more difficult to integrate with.
The Challenge
There are many sides to this problem:
For the average Nigerian bank, many FinTechs are knocking on the door requesting APIs to do basic things such as payments, validating data, collections, etc. Many are developing custom APIs which don’t scale to other implementations. Keeping track of who is connected to what is a challenge. Monetization is a difficulty.
For FinTechs, (I suffered this over the last few months), convincing banks to allow connectivity is met with apathy, distrust, and unbearable burden. Each bank comes with custom integration methods and codes. Many banks never allow connectivity, so the world-changing solution dies when the Xth bank joins, two years after.
For risk managers, (you know yourselves!) the new craze of FinTechs, apps, and services is a disaster waiting to happen. The surface area for which a breach can occur expands with every new connection, and nevertheless, the product managers are blaming risk + control managers for being cogs in the wheel of progress.
The CIO that wants to implement a robust ESB solution, which adequately caters for different external applications connecting with core banking solution, is faced with complicated software that is expensive to buy, implement, support and integrate. By the way, nobody else in the industry knows how the software works and so when the smart cookie who runs it resigns, the solution is abandoned after two years of never-ending implementation.
So what is the Way Forward?
I have faced this problem in almost all the dimensions possible. However, my current experience in FinTech and as an outsider looking into banking has shown me how crippling this is for banks, FinTechs, risk managers, CIOs, etc.
However, my broad experience has also demonstrated that we stand, as a country, at a junction by which this problem can be solved simply, cheaply and everyone would be a winner.
It would be an open-source, non-partisan API standard for banks and other OFIs.
Why not PSD2 or Open Banking Project (UK)
The problems banks and FinTechs currently face also plaguing everyone in Europe, and they consequently came up with EU Government backed PSD2 and industry-led Open Banking.
Ordinarily, it would have been easy to fork their project for Nigerian banks. Unfortunately, their implementation could be expensive, complicated and time-consuming for anyone to implement.
Developing what works for our environment, regulation, our level of technical maturity, etc. may have a greater chance of success than wholesale adoption of international standards.
However, references would be made to international best practices where and when it suits the local objectives.
Problems the Open API Should Solve
This initiative should solve practical problems of payment interconnectivity for different industry player:
Banks: A non-proprietary API infrastructure which any of the FinTech and other partners can connect with simply and securely. It would be easy also to monetize the connections, set limits and enforce transaction integrity
FinTechs: With every bank adopting the interface, connecting to each would be a breeze. They can focus on building amazing solutions without wasting time and effort convincing each bank for connectivity and also developing extensive custom codes for each
Risk Managers: With a single doorway that provide a consistent interface and means for managing external integrators, risks can be reduced, and threats can be easily seen and controlled
Product Managers: FinTechs are not foes but friends who can multiply a bank’s transactions and together bring new sources of revenue, especially in the new regime of low transaction fees
Industry: The Open APIs will also provide a level playing field for everyone which ultimately allows innovation to grow while preventing bigger players from stifling others because of legacy connectivities and platforms
The Open Banking API Tenets
- Non-partisan
It will not favor any company, groups or sector over another. Contributions shall be accepted from everyone - Open and free for anyone to use
The standard shall be free for anyone to use - Technology agnostic
While the interface would be standard driven, how each bank, OFI, etc. choose to implement would not be dictated - Simple to implement
It would favor simplicity over gimmicks or exoteric functionalities - Secure
Security would be inbuilt from grounds up to engender confidence by companies, regulators, and other stakeholders
Starting Up
While the API standard would be open and free for anyone able to contribute, we all know that it has to start with something and with some people. Each of you receiving this email has been previously approached and selected for various reasons and skill set.
A draft document outlining objectives, design, and API definitions would be developed and released for additional inputs. The final document would be robust enough to be presented to the general public for adoption.
Key areas that need help would be for API design, security, scalability and regulatory.
Conclusion
It has been a long email and thanks for reading this far. Questions, comments and other contributions are welcomed.
Best regards,
Adédèjì Ọlọ́wẹ̀
www.dejiolowe.com