We often get the “Build versus Buy” question from banks, which we started to dive into in our ‘Why you shouldn’t develop your own ERP Adaptors’ post. One of the most important aspects of BvB analysis is how many pre-existing tools you can take advantage of to get your application to market.
We have witnessed the renaissance of app development over the past decade as famously predicted by Marc Andreesen’s “software is eating the world article in 2011.
This growth has driven the decrease in development costs for application developers. The recent proliferation of powerful platform tools that build and distribute digital applications allows developers to prioritize their time. Developers can now focus on designing and building valuable user experiences instead of building commodity features or building non-functional requirements.
Standing on the Shoulders of Giants
There is an idea in the physical sciences called the percolation model and the same concept can also apply to innovation. In short, the percolation model describes how many parts of a system need to be beyond a certain threshold in order for something to pass through to an end state (ex. the number of trees that are aflame before the fire will spread through the whole forest).
In deep technology, it requires a certain amount of hard discoveries to breach the threshold. Once it is breached, innovators will rush into the problem, each solving the final mile innovations with slightly different twists. This model can be attributed to many historical discoveries and their uncanny subsequent discoveries.
For software development, this idea is likely better understood in the number of reusable elements that are available to any application developer. These powerful hardware tools are generally in the form of APIs, SDKs and Open Source Coding Frameworks.
Below are examples of how popular apps are really just composites of a wide range of APIs. While the exact underlying API brands are just illustrative, they are also only a representative of a small portion of the tools used by those developers.
I found these principles on routifics blog, and while they are remarkably biased as an API service provider I believe the logic is perfect. Modern application developers should adopt the following principles as part of their development.
There are issues not only of cost but of quality. What are the odds of your team improving the quality of a service that is also being used by hundreds of other developers and learning from hundreds of other data sets? Avoka and Forrester found that projects trying to reuse internal APIs from banks were more likely to become delayed. While counterintuitive, it speaks to the idea that your internal projects do get experiences or maintained in the same way as external apps.
What does it mean for banks?
This kind of platform thinking is important for banks and financial services for a number of reasons. The biggest reason is that these tools don’t exist for banks and Finn-app developers in the same ways they do for other types of industry verticals. While today a bank might be comfortable leveraging AWS, Kubernetes and some fancy open source dev frameworks to get a new application to market. Those types of elements are relatively low-level close to the machine-type tools; the transition to higher-level (Closer to the user) bank-grade components available as a service will eventually happen.
The most common piece of highly functional, reusable code for banks are those such as Plaid or Yodlee, which have been used by hundreds of Fintech apps and many banks themselves. Those services have gained wide distribution despite questionable functionality and often questioned legality.
There is a wide range of emerging technologies that will solve for some of these issues creating highly reusable tools with great utility and easily accessible via API. Options like Marqeta, Trulioo or the Card Networks own API tool suites will become even more important building blocks. In the future, entities such as Synapse, Finix, BBVA Open Platform and Cross-River Bank will offer whole chunks of functionality to banks.
Specifically treasury and business banking?
When it comes to B2B use cases, the platform tools available to a commercial/corporate bank or Fintech are even slimmer. The impactful applications that banks or would-be disrupters will build in the future will require a novel combination of access to banking services, the clients own erp/business application data and a sprinkle of useful third party functionality (GPI Payment Status Tracking, or Antifraud screen service).
The kinds of powerful platforms that could increase the banks time to market speed or lower their costs of development for these specialized apps don’t exist today or are otherwise unfit for their purposes (Read Only, where reader write would be required). However, that will not remain true forever. I believe that if B2B fintech investments sustains pre-pandemic levels (or even grows) we will see at the start of a developer tools renaissance as a proliferation of new tools come to market.
In the meantime, the lack of these accelerants means two things. Firstly, that “renting” applications might make more sense than a building, FISPAN has many out of the box use cases that our banks can deploy in a matter of weeks. Secondly, it might also mean working with a partner like us to extend and build upon our platform to suit your purposes. We have started to expose FISPAN API endpoints that aggregate the bank’s own capabilities with client ERP data and multiple supporting services to the bank's own developers, clients and partners.
Don’t build alone, build upon what we have done.