APIs and API economy is something the whole tech-world is currently buzzing about. And rightfully so. Never before has the design and understandability of a technological interface defined the success and scalability of a business.
While it may seem like everything today is made available via APIs and that it is a quite straightforward business to allow systems to speak with each other, there’s a whole other side to it. Building APIs the way they would benefit one’s business is an art of its own.
In fintech and banking, numerous industry players have experience in either building APIs or integrating with them. As it is usually up to companies and developers to design the APIs as they see fit, it’s positive that standards like PSD2 and Open Banking define a common contract for designing APIs, leaving no room for individual interpretation and harmonising the field to a certain extent.
At Tuum, we are engineering an API-first core banking platform, meaning our APIs are the only access point to our business logic. From this perspective, we consider APIs as the most valuable part of our business and treat them as “first-class citizens”. Hence we have to guarantee their consistency and reusability, which means we spend more time on design than on actual development.
This approach has provided us with an in-depth understanding of how to build APIs in a manner that would lead to customer success stories.
Applying the API-first approach
Designing APIs is a well-defined procedure thanks to technical design patterns, such as REST and HATEOAS. These patterns provide solid guidance for developers and help to avoid costly mistakes.
But designing technically correct APIs is only half the story. It’s equally important to understand how they canThe other half being how well they support the business. To consider an API designed as API-first and business-first, it must support the business domain and the necessary operations in the domain.
Sounds simple and obvious, but a lot of companies still struggle with these issues daily for that they underestimate the complexity of business processes and different consumers’ needs.
Let us illustrate this with a use case of a new fintech that wants to launch a bank account offering to the market with superior user experience.
Fintech launching a bank account offer
On the business process side, an easy solution would be to build an API for every singular operation (for example creating a customer). Unfortunately, this is true only if the business domain is relatively simple. For our fintech, creating a new customer means initiating a lengthy onboarding and KYC (Know Your Customer) process that can last for an extended period of time.
From an API consumer perspective, the fintech does not want to know about the complexity of the background process. However, what they do care about is an option to easily initiate the customer creation process and get customer data and their status in the process, with the sole purpose of the end-user to have an exceptional customer journey.
In the case of API-first design one has to guarantee that minimal necessary data is gathered with as few API calls as possible (ideally one). It is also important from the data consistency perspective. The more API calls the consumer has to make, the more probability there is for data inconsistency due to different types of potential errors. Secondly, consumers must have a way to get the status of the internal processes and interact with these in an understandable, well-defined manner.
APIs must enable the same business capabilities for any customer touchpoint, whether it’s mobile applications, web applications, or smart devices. The main challenge with different touchpoints is that the amount of data required usually differs in order of magnitudes. For our imaginary fintech, their customers want to see account details, balance, and list transactions in the mobile application. In their smartwatch, they just quickly want to check their balance without being shown other distracting information. The fintech from its back-office wants to see all the data about customers, allowing insights for the future and offering excellent customer support.
Another thing to consider is the size of the API response payload. Although it might be tempting to include all the data into one API, this automatically slows down the response rates, and if there’s something the users are not fond of, it’s waiting. Delivering quick response times is extremely important. For doing the latter, the API payloads need to be optimized accordingly.
Long story short: designing APIs for business success
One thing is to build APIs, a completely different thing is to build APIs that will actually contribute to business success. In order to follow the API-first approach and make sure the APIs benefit one’s business, the focus needs to be on the design rather than on the development of the APIs.
This understanding is something that many companies are still struggling with, as they are overlooking ‘ the needs of the consumers as well as the complexity of their business processes.
Therefore, when building an API, ask yourself these three questions:
- Does it contain all the necessary information relevant to your business domain?
- Does it minimise API payloads, optimising for the fastest response times possible?
- Is the hygiene of good security practices such as authentication, authorisation and encryption, versioning, error handling or filtering assured?
If yes, you’re good to go – the API is designed in a way that allows it to act in the best interest of your business and to create customer success.