Business leaders at digital financial services (DFS) providers who are responsible for opening APIs can have their hands full designing a new API business model, creating new processes and sourcing the new people and technology required for implementation. Considering all these responsibilities, they might prefer to outsource the technology-related matters of their API initiative to their IT counterparts. That might be wise, but it is still critical that business leaders be fluent enough in technology to have informed discussions with their IT teams. Business leaders must be clear on what they need technology solutions to deliver and why, and they will want to be able to ask IT teams the right questions to inform investment decisions.
While implementing open APIs is about more than good technology, inappropriate technology decisions can severely hamper the probability of success. This is particularly true when the business and technology teams are not aligned on what is required. When this happens, it can lead to technically unreliable solutions, cost overruns, poor user experiences and low API use.
Below are three design principles from a new CGAP slide deck, “Technology Building Blocks for an Open API Strategy,” that business leaders should keep in mind when making technology decisions.
- Adopt a self-service mindset. DFS providers should ensure their technology enables third parties to start using APIs with as little intervention as possible from the operational and support teams of the DFS provider. This is important to ensure the DFS provider can acquire and service third parties at low cost, even as the number of third parties begins to scale.
Excellent API documentation and a sandbox that simulates live system behavior and enables third parties to fully test their own system before they go live are essential for self-service. The technology also should enable the commercial elements of the relationship between the DFS provider and third party, making it easy for third parties to monitor use, understand and address failures and trigger settlement of their funds – all with limited effort from the DFS provider.
- Protect your reputation. Open APIs can expose DFS providers to various risks. Well-designed API contracts can mitigate such risks. Technology also can help mitigate security, data privacy and other risks that can negatively impact your business. An API management platform can allow risk and compliance teams to authorize faster and cheaper onboarding practices that are just as secure as existing partner onboarding processes. Examples of risk management policies implemented through an API management platform include ensuring only authorized third parties access different APIs and controlling the number of API calls per third party as per access policies and risk considerations. Technology also can enable a provider to obtain and revoke consent with minimal inconvenience to end customers.
- Create an awesome third-party experience. Because third-party developers are a new type of customer, technology decisions need to ensure an awesome experience for these new customers along their journey from awareness to growth.
The Third-Party Journey
The goal of the DFS provider is to efficiently move third parties toward use and growth. This requires a smooth third-party experience. You’ll need a well-designed developer portal that clearly articulates the value your APIs can deliver, facilitates a smooth onboarding process and provides clear API documentation. The portal also should enable developers to support each other through a community forum, ideally leveraging tools that the developers are already familiar with such as Slack or Github. The DFS provider will want to provide direct support for certain third-party segments, and this can be facilitated via ticketing platforms like Intercom or Zendesk.
Lastly, DFS providers will want to ensure third parties can access data to better understand and grow their business. The figure below illustrates how Paystack, a Nigerian payments provider, provides analytics to help third parties understand API use patterns and respond accordingly.
To achieve this enhanced experience for third parties, the business and risk teams need to understand the myriad possibilities enabled by their technology and adapt onboarding and go-live processes to get the most out of it.
For more detailed guidance on how business leaders can navigate the technology decisions required for an API initiative, see “Technology Building Blocks for an Open API Strategy.” The deck draws on the experiences of five DFS providers in opening APIs in emerging economies.