In part 1 of our Embracing the APIconomy blog series, we urged banks to embrace the APIconomy by opening their gates, providing open APIs and, thus, joining forces with FinTechs and other third-party providers. In doing so, open APIs become products and should be treated as such. You’ve probably heard that before. So, what does it really mean? APIs add an additional set to your bank’s customer base: third-party developers. Hence, it implies that users of such APIs, i.e. developers, should be treated as customers of your bank. That requires an additional value proposition.
Before you try to define one, you should think about your overall Open Banking strategy – what is it that you want to accomplish? Expand your service offerings on your banking platform, or focus on the monetization of existing data to create new revenue streams aside your platform? Simply complying with PSD2 is evidently no lasting solution as customer-centric bank. While new revenue from data can be a lucrative monetization opportunity, solely focusing on this may be risky. You can’t neglect your initial customer set: end customers. And they expect an innovative banking platform. Integrating third-parties into your product and service offering will both spur innovation and open up monetization options.
Developers want a convincing experience
Once you’ve figured out what it is that you want to accomplish, it is time to think about what value you can offer to developers. Think of developers as your typical millennial customers. They know what they want, they want it as easy and hassle-free as possible, and they want it now. A reliably functioning and easy-to-use API is taken for granted, compelling value is what you can offer along with it.
Enter developer experience (DX): The sum of all experiences a developer has while interacting with your bank’s API. Like products, APIs need to be managed to actively shape that experience. A well-designed developer portal can make that possible:
- Registration process: Make it easy to register on your portal
- A clear documentation is imperative: Provide code samples, guidelines, case studies, tips, and a getting started guide
- Developer community: Allow developers to help themselves and provide feedback in forums – build a community around your product
- Share news: Regularly put hot topics on your blog
- Support: Have an easy and fast way to report bugs or contact you with problems and questions
- Fun: Events such as hackathons or competitions are a great way to add some entertainment to your API. It’s also an easy way to spread the word and promote your API.
Manage your new set of customers
Third-party developers have various interests that are hard to amalgamate. A three-tier model is a great way to distinguish between user groups of your API. We generally recommend providing a free self-registration to any user who wants to test and play around with your banking API. This allows them to self-select and apply for the next engagement level when ready.
Ideally, when developers recognize the value of your API and have specific use cases, the engagement with them should change and they would move to the next level. Value to the API user obviously increases with each tier, exemplary benefits for each level are shown below.
When it comes to implementation, it often makes most sense to start with a minimum viable product (MVP) and a handful of partners. Once that has proven successful, the developer portal should be made publicly available. Of course, increased value comes at a price. Monetization strategies and security expectations increase with higher engagement levels. We talk about that in more detail in article 3 and 4 of this blog.