PSD2 / API Programmes: Engaging with Techies
PSD2 and CMA Open Banking in the UK place a requirement on banks to put in place some level of support for open APIs. The extent to which banks also see APIs as a business opportunity is not clear for the moment, and the degree of interest definitely varies across the different regions in Europe.
In its 2016 State of APIs report, Apigee claims North American enterprises are 6 – 12 months ahead of their European counterparts in digital transformation initiatives. Perhaps PSD2 and CMA will reverse this trend in the banking space.
Business reasons for focusing on API as product
Whether or not open APIs are seen as an opportunity in the banking space, it is clear that mobile technology is critical for delivery of many bank services. It is also clear that developing all technology in-house is a major challenge, that consumers have a strong appetite for novelty and convenience, and that the need for well-controlled robust and stable core banking services remains. Banks need third parties for rapid App development. APIs are crucial if you want to marry the rapid R&D cycles required for App development, with the more mature development cycle required for back end banking services.
CapGemini do see PSD2 as an opportunity for value creation (see here). They cite one example of a bank that provides an API service for buying foreign currency. The API is used by an online travel services company to sell foreign currency to its customers. In this way the bank opens up a new revenue stream at a very low sales and distribution cost. A second example cited by CapGemini describes how a French bank created a single App in one year based on their own, closed API. Once they opened and monitized the API, third parties built 80 Apps in two years.
Engaging with Techies
In our previous white paper, PSD2 & CMA : APIs and changing IT Demands, we explained how banks have delivered banking services via technology for many years, but that this new technology wave brings new challenges. Product managers and business development at the bank will need to engage more with the world of techies, and much of the communication with technology partners will itself be mediated through technology. In this paper, we’ll look more closely at the role of the product manager and business development in API Programmes, but first we give a bit of background on the API programmes and some of the general purpose API technology that will be used within the programme.
API Programmes
Figure 1 shows the parties traditionally involved in providing IT-based access to bank services. We can expect the same parties to be involved in an API Programme.
Figure 2 gives a simple depiction of the API lifecycle and identifies the phases where the different parties are involved. In API Programmes, we can expect that product management and business development will be less insulated from IT activities, and will need to be more knowledgeable about the technical activities engaged in by partner IT.
API Platforms
The primary new infrastructure required for an API Programme is an API Platform. The Platform’s main function is to publish and secure APIs. The Platform will likely be introduced as a layer that interfaces with bank middleware e.g. as shown figure 3.
No traditional bank that we are aware of are considering building their own API Platform. Even BBVA, an early entrant to the API Economy in the banking sector, is working with what is now a commercial platform. The API Platform developed for BBVA by Beeva, a technology company owned by BBVA Group, has been launched on the market as an independent API Platform product called APIVERSITY.
There are a range of API Platforms on the market, many of which have been acquired by large vendors over the last few years. Vendors include IBM, CA, Axway, Apigee (now Google), Mulesoft and Akana but there are a whole host of other interesting vendors. The 2016 Gartner Magic Quadrant report on Full Lifecycle API Management provides quite a comprehensive listing of the vendors, and is available for download from some of the vendor sites.
Apart from general purpose API Platforms, there are also some platforms on the market that are focused exclusively on providing APIs for the banking domain e.g. Figo and Temenos Open Bank Project.
API Platforms offer a range of capabilities. Some, though not all, will include a Developer Portal. The Portal is designed as an entry point for users of the API. It typically provides documentation, an easy way to create first draft APIs, and a way to interact and play with the API. Figure 4 gives an idea of how API documentation might look, in this case the API is being presented via the open source Swagger UI application. The depth of functionality included in the Portals varies. None of the Platforms include a good mechanism to present business rules and simulate responses that reflect real behaviour.
It is important to remember that an API Platform is a technology solution. Even though some of the API Platforms will provide a PSD2 reference implementation with example banking APIs, the banks must prepare, document, secure and test its own APIs. Bank-specific APIs must be implemented, and the Developer Portal populated with detailed bank-specific information including bank business rules.
Banking services are mediated through the API technology layer. Product management and business development will need to understand this layer to some degree.
Product Management
Product management has a challenging role. They need to prepare an API product – a suite of banking APIs – for as yet un-thought of services. In creating the product, they need to engage with a broad constituency of stakeholders : banking domain experts, thought leaders in API design and the API economy, technologists as creators of the APIs, and technologists as end users of the APIs. Services powered by the APIs could range from services developed by third party Fintech companies, to services developed by the bank using in-house data analytics, or created with a combination of its own and third party bank API services.
The product manager must get the product/market fit right, make judgements on revenue potential, and understand what is technically feasible. They will need to be involved in selection of the API Platform to ensure that it fills the business needs and the technical needs.
Importantly they will need a good and crisp understanding of the services that can be delivered via APIs, and they will need to be able to communicate clearly on this. The API product is a technical offering and meaningful engagement with various stakeholders will depend on communication that explains the APIs well.
A great approach is to create some example APIs, and provide a lightweight sandbox for the examples. In our experience a sandbox for well-constructed examples really helps a non-technical audience to understand what the APIs can do, and really helps a technical audience to grasp the business purpose of the APIs. You establish common ground that allows conversations to develop in a tangible and meaningful way.
With the right tools in the right hands, example APIs and the sandbox can be created within hours. Most API Platforms will support this type of capability, but there are other options if the team has not yet selected its Platform.
Business Development
Business development will need to construct an ecosystem of partners : a combination of AISPs and PISPs from the PSD2 world, young Fintech companies in incubation mode, and preferred partners for outsourced App development.
When promoting services to this type of ecosystem, they will need much more than an implementation guide in PDF format. At an early stage in an API Programme, banks will often run hackathons and innovation programmes to kickstart engagement with developers. But they also need to have a more ‘hands off’ process in place that encourages partner engagement. They will need high quality online technical material and entry level sandboxes where partners can evaluate whether the bank services are suitable for their needs. Partners will expect to be able to evaluate with minimal effort before a commercial contract is put in place, and perhaps even before they have any direct contact with the bank.
Business development will want to understand the progress of partners : through the onboarding phase as well as when they go live. Have they registered to the sandbox and tried it out? Have they tested against the APIs they plan to use? Once live, what volume of transactions are being pushed through the bank? When is the right moment to discuss the business case, revenue potential and co-branding opportunities?
Automating communication, lowering costs
Engaging with techies means offering more developer-friendly ways to understand and use banking services. Product management and business development will need to be comfortable with the technology platforms, and to understand the APIs at a level that will allow them to communicate effectively with technologists. Some concrete steps that will be useful for product management and business development are :
- Use realistic APIs in a sandbox to aid in explaining the business purpose of the APIs;
- Ensure that a high quality playground or sandbox is available where 3rd parties can evaluate APIs independently;
- Gather information and metrics from the sandbox and API Platform about partner activity.
If approached correctly, it is possible to automate a lot of the communication, and developers will thank you for it. Developers like desktop research. If banks want to engage with and onboard an ecosystem of developers and partners at low cost, they will need to put in place infrastructure and technical content to support that.
XMLdation Solution for API Programmes
XMLdation provides a cloud platform for managing API Definitions. Banks can author documentation and business rules about its APIs. They can generate online implementation guides, example API requests and responses, and lightweight API sandbox implementations with strong bank-specific diagnostics. The material can be published to the XMLdation Developer Onboarding solution, or to the Developer Portal contained within an API Platform.