Embracing the APIconomy (II): Meeting customer expectations on the developer side

Publish date:

To maximize the value of your APIs in the APIconomy, think of third-party developers as a new set of customers with distinct expectations. Offer them an engaging developer experience (DX).

Figure 1 Overview

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.
Figure 2 Developer experience (DX)

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.
Figure 3 Proximity to the end customer increases from Developer to Partner in the three-tier modelIdeally, 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.

Figure 4 Value to the API userWhen 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.

Weitere Posts

Data Management

How to implement the Data Management Flywheel methodology

Capgemini DE
Date icon September 19, 2018

Data is the lifeblood of modern financial institutions. These are the three biggest challenges...

Data Management

Data Management – the foundation for a successful and consistent IFRS 17 and IFRS 9 implementation

Tobias Mohr
Date icon September 18, 2018

Data Management is the foundation for a successful IFRS 17 and IFRS 9 implementation. Capgemini...

Artificial Intelligence

How Shared Service Organizations rethink their way of doing business

Max Scheuermann
Date icon September 17, 2018

Shared Service Organizations rethink their way of doing business – From transactional...

cookies.

Mit dem Fortsetzen des Besuchs dieser Website akzeptieren Sie die Verwendung von Cookies.

Für mehr Informationen und zur Änderungen der Cookie-Einstellungen auf Ihrem Computer, lesen Sie bitte Privacy Policy.

Schließen

Cookie Information schließen