Open Banking and Open Finance has arrived and now what? How are we going to achieve the Banking-as-a-Service (BaaS) model?
One of the biggest challenges for today’s CTO is to define a way to create and monitor the success of an open banking project. This article sets out a step-by-step approach for the bank to expose its data in the form of digital services – to meet the country’s regulations, to create a digital product to sell to third parties, and to generate business.
An API is nothing more than an interface to connect applications and share data. John Musser pointed out that for an API to be great, it needs to:
- Deliver a valuable service
- Have a plan and a business model
- Be simple, flexible and easy to adopt
- Be managed and measured
- Offer an excellent support to developers
With that in mind, I’ve listed six essential topics for the exposure and control of digital products through APIs:
- Infrastructure preparation (API Gateway / Developer Portal)
- Digital product definition (API design, data scope, values to be delivered)
- API exposure (Market standards: RESTful APIs, OpenAPI spec, Oauth)
- Product validation (Pilot partner)
- Creation of indicators for quality management
- Maintenance and evolution
1. Infrastructure preparation
The first step is to prepare the infrastructure to support the exposure of the institution’s financial services. Regardless of the technologies adopted – programming languages, frameworks, microservices or monolitic systems, it doesn’t matter – the most important thing now is how you are going to expose it externally for the Web. For that you need an interface for the world, which is going to be available for third parties to plug and play with intuitive documentation.
The necessary infrastructure for this integration resumes relies on two key components: API gateway and developer portal.
1.1 API Gateway
The API Gateway is an interface with the external world. The Gateway intercepts all the requests, processes them and accesses the bank’s internal services in a technology-agnostic way. The internal services then send a response which the Gateway again intercepts and processes, before sending it to the API consumer.
The API Gateway makes life easier. It becomes the single point of entrance for all web requests, where all the necessary processing can be easily managed. The exact Gateway function varies from one implementation to other. Common functions include authentication, routing, monitoring, analysis, policies, alerts and security.
Processing and services available in the API Gateway include (for example):
- mapping of input and output fields for requests and responses
- access control through scope management and market standard authorization protocols such as Oauth
- management of application keys that will use the Gateway
- control of requests by Application Keys (access quota control)
- log control and information for monetization and auditing
- control of black-list and white-list by IP
- API versioning control
- monitoring the health of APIs
- API testing
- orchestration of internal services
- traffic load balancing to protect infrastructure
- protocol adapter (HTTP, HTTP/2, Web Socket)
- and so on…
This is an important tool. Due to its complexity, many banks choose to buy from a company that will maintain it such as Amazon API Gateway, Google Apigee or Sensedia API Platform. There are also Open Source examples, such as Kong API Gateway, Apache APISIX and Tyk among others.
Should I buy or develop it in-house?
I leave this answer to you, as there are advantages and disadvantages to be analyzed. To help you, below are some pros and cons.
You can find more build or buy guidance and examples at Open Bank Project.
1.2 Developer Portal
This component has an important role, because it will be the first contact with the partner’s developer that wants to integrate. The focus here is the DevX (Developer Experience).
Your bank can have the best API exposed, but if developers from outside the bank environment are unable to use it – because integration documentation and onboarding are too complex – or do not have the backing of your support team, the open banking project will be a failure. The developer experience is vital to succeed in the Banking-as-a-Service model.
The focus here will be a web page. Good practices basically include:
- management of the partners registrations and application keys
- intuitive integration documentation
- examples of request and response (in different programming languages)
- clear descriptions of what each API resource does and the meaning of each input and output field
- descriptions of the sequence of resource flows for each business purpose (for example, the sequence of API resources that needs to be requested to get a real estate financing)
- sandbox to perform tests before going to production
I emphasise again: this step is very important and deserves special attention and investment. The developers who access your Portal will be your strategic collaborators, offering your product through their applications. The more collaborations, the more your products will be requested and the greater the profit.
2. Digital product definition
The design of the digital product is very important for the experience of using the APIs. Your Product Manager should understand what an API is. The API can be the product itself or the connector to improve other metrics.
An effective API program is based on the company’s institutional strategy, helping to achieve its objectives. The API’s objectives are: to develop new partnerships, increase revenue, explore new business models, accelerate time-to-market and establish new distribution channels.
There are three questions that your team must answer:
- Why do we want to implement the APIs?
- What tangible results do we want to achieve with these APIs?
- How do we plan to run the API program to achieve these results?
To define the value of your API, there are 5 questions:
- Who is the user? To answer this, consider the users’ relationship with you (are they current customers, partners or external developers?), the role they have (are they data scientists, mobile developers or operational employees?) and their requirements and preferences.
- What user problems are we solving and / or what benefits will we generate for them? Consider the customer’s business, the challenges and gains defined in the value proposition, if any critical needs are being met (is it a problem or opportunity to generate profits?) and what metrics will be improved (speed, revenue, cost savings or innovations deployment).
- Which use cases does your API work for? Identify them with the help of the value proposition, the solutions to the user’s challenges or the opportunities generated by the APIs that are most effective for your company and the user. Plan the API to handle these use cases.
- How will user value increase over time? Prepare the value proposal considering future changes. What are your main future project checkpoints related to external and internal changes?
- What is the value generated internally for your organization? Consider the internal benefits and how valuable the API can be to business.
It will also be necessary to define a business model. Every API generates a cost for the company, and this cost must be justified. Never start exposing an API that will not make a profit or savings for you (unless you are a public company or an NGO). It is essential to have a clear monetization strategy.
Potential monetization models include:
- Freemium – the customer will not pay anything up to a certain limit, then there will be a charge
- Tiered – billing is by volume of requests
- Fixed – there will be a fixed payment for certain periods by the partner
- Commission – or revenue-sharing for services sold through use of the API
- Free – but you will get some information from the partner (for example, by also consuming the partner API and thus adding value to your products)
A Service Level Agreement (SLA) must be created to be provided to your API’s consumer. This contract defines availability, maximum number of requests per minute and other terms that will protect you from possible complaints and lawsuits, and will guarantee the quality of that digital product.
3. API exposure
As we can see, it is work done by at least six hands: product, business and technology. In the exposure phase, you need a team specialized in integrations, with knowledge of market standards, because API Design is very important for the success of your product.
The idea of the digital product is that it should be as reusable as possible, That’s why market standards for system integration should be applied, such as the REST standards, the Oauth authorization protocol, the OpenAPI integration documentation, the use of mTLS, MFA (Multi-Factor Authentication) when necessary – in other words, all the technological resources that are well known by the application development community. The simpler the integration is, the more partners will be connected to your product and the greater your revenue.
This stage is carried out using the API Gateway (as mentioned in earlier) where access to resources will be centralized, with all this parameterization consolidated.
4. Product validation
Before making the product generally available, a pilot with a small numbers of partners can more accurately validate the service. In the case of creating a new digital product, I suggest that even before this stage of exposure, a Design Sprint or some prior validation methodology of your preference be done, so that you can save money before you allocate any major investment during the following steps.
Once exposed, we now have to track the success of our product. That is why it is important to have a very precise analytical tool, with access to the API Gateway log. It is there that we will monitor availability, accesses, partners, generate ticketing and so on.
5. Creation of indicators for quality management
Using analytical tools, we will assess the success of our digital product that is already available. There are some important points to consider.
Here are some important topics to configure in your analytics tool, to measure the success of your digital product via API:
- Business Value – revenue per API, cost of APIs, generated payments, successful API calls, number of customers using the API
- Customer Experience – Active users, response time and availability, number of TPPs used by each customer, number of customer renewals allowed for each service
- Platform – Number of TPPs within the ecosystem, number of transactions per TPP, number of TPPs per API
- Developer Experience (DevX) – Number of developers using the sandbox, number of developers using products in a real environment, number of programming languages available, developer integration time, total number of APIs available
- Security – number of fraudulent transactions, successful authentication by TPPs and customers, generated and expired tokens
6. Maintenance and evolution
With the indicators listed, it is now about defining goals and tangible objectives to increasingly improve your Open Banking project, and to be more successful within this new ecosystem.
An example of methodology is the OKR, so that from the indicators mentioned above you can create your key results with well-defined targets.
Further steps – BaaP
Beyond this, there is a section option: to turn your bank into a Platform (BaaP), the so-called Banking-as-a-Platform. But this first step (BaaS) is already quite profitable and is a prerequisite for creating a platform, where there will be a high concentration of exposure and consumption of APIs, and the structure to be used will be practically the same.
It is worth noting that with the pandemic, the acceleration of the digital world, the arrival of 5G expanding the bilateral flow of information, among other factors, the market value of Open Banking is expected to reach more than 43 billion dollars by 2026, according to Allied Market Research.
The idea of this article is to be succinct, but I could also go deeper into the issues of the ideal organizational structure and strategies for creating goals when the company is organized in silos, but I will leave that for a next chapter.
Did you like this article? I welcome feedback, please get in touch!