Open banking: Developer friendliness as a competitive advantage

Open banking is one of the factors that will shape the future of banking, and at the heart of open banking lies APIs. However, just opening up your APIs provides little to no value unless developers actually want to use your APIs. Providing an excellent developer experience crucial to keep your external developer community engaged.

But first, a short recap on APIs and why they matter:

An API is in its simplest form a standardized protocol for computer programs to talk to each other and is integral for modern software development. The use of APIs range from web-based APIs, operating systems, databases, hardware, or software libraries.

An API specifies the connection mechanism, the data, and functionality that are made available and what rules other pieces of software need to follow to interact with this data and functionality. Although have been used to link software components within an organization for a long time, the Internet has given rise to the popularity of external web-based or public APIs. An organization can use a public API to allow third parties to access their data or services in a controlled environment. Using an API means that only desired aspects of software functionality are exposed, while the rest of the application remains protected.

When setting up public APIs, the developer experience should be given the same level of care and attention as your consumer-facing user experience.

Provide a sandbox as a starting point. This is the easiest way to start exploring the magnificent world of open platforms. Create an environment that mirrors your production environment and encourage developers to test out your APIs (as well as taking them for a spin yourself). This is a great way to get developer feedback on API-design in a risk-free environment. Take the lessons learned from your sandbox playtime with you when designing robust APIs for production.

Communicate regularly with your developers. Provide insight on your platform roadmap in order to entice anticipation on what lies ahead. Be transparent on scheduled maintenance as well as unexpected downtime. As your selection of APIs expands, consider offering a sort of marketplace/gallery of available APIs as well as a way to monitor API status.

API governance must be designed with a risk perspective in mind. Appointing dedicated resources with backgrounds from both security and business development in charge of API usage is integral to maintain a balance between risk mitigation and innovation. This relates to both carefully selecting who is given access to your APIs as well as continuous monitoring of potentially suspicious or unexpected behavior. Make liabilities and terms of use unambiguous and easy to understand. Make sure non-lawyers can understand the legal obligations.

The business model should be transparent and easy to understand. Letting developers try before they buy on a freemium basis is preferable when applicable. Don’t be afraid that you are giving away anything for free. The code required to make use of an API is usually more valuable than the unit price of a couple of thousand API-calls anyway.

Good documentation is an absolute. The language should be consistent and provide detailed instructions on how to use your APIs. Do not assume that developers considering your APIs have a certain skill level or prefer specific language. If third-party libraries are required to make use of your APIS, make sure to specify so in the documentation. At the same time, make sure your APIs are responsive enough for those who do not bother to read the documentation and opt for a trial and error approach to programming.

When done right, having powerful APIs can act as a catalyst for growth. As proven by Stripe, the online payment company that can credit much of their success on having APIs that are described as a dream for any developer wanting to build payment processing into their site.

For more on open banking, check out my previous blog posts on the subject.