Why is that ? Because in most cases APIs have been implemented as an additional layer to existing systems. This gives rise to a number of problems that can cost companies money and undermine the confidence of their customers and partners who rely on their systems. Let us explain why APIs should instead be treated as "first class citizens” to create an architecture that is both functional and scalable.

Poor foundations…

APIs have emerged as the solution to modernize banking systems in the face of a double phenomenon: first, the wake of new technologies that heightened customer expectations, and second a constantly morphing regulatory environment that introduced new imperatives and simultaneously new forms of competition. In particular, the PSD2 (Payment Services Directive 2) requires European banks to create Open Banking APIs in order to open up their customers' data (related to payments, accounts, loans...) to other banks and fintechs, thus making the banking sector more open and transparent. According to KPMG's Open Banking Observatory, the faster banks obey the DSP2, the more likely they are to move from being "compliant" to "competitive" by adapting the open API approach to use cases beyond the PSD2 framework, or even "innovative" by creating new services (new distribution channels, monetization of statistical tools, bank-as-a-service…).

As a result of these two phenomena, the banking system appears as a two-headed hydra: on the one hand, traditional banks with aging infrastructures and inefficient business processes, and on the other hand, fintechs that offer more efficient financial services at lower costs thanks to innovative digital solutions.

Traditional banks have long been siloed organizations, composed of different departments that use a patchwork of disparate systems to meet their own objectives. In their quest to digitize workflows and minimize paper-based processes, they have brought on board a variety of standalone software solutions which, when pieced together, allow the completion of banking processes. However, the remaining disruptions require human intervention, resulting in digitally incomplete workflows. That’s not all, implementing these standalone tools typically demands substantial coding by the IT department. They also don’t integrate well with existing systems, and therefore don’t communicate automatically with each other, hence creating information silos.

This is where APIs entered the field. They held the promise of integrating these disparate systems and services into unified platforms where they can exchange data and perform a set of routines in collaboration with external systems.

… and a poor implementation logic

In this logic, APIs are implemented as an additional layer to existing systems. The latter were already working before the introduction of APIs, so when developers test them they don't go through the APIs. Consequently, a number of performance issues go undetected because the right checks are not performed on the APIs : problems of volume, user load, performance regression after a several iterations, etc., which generate errors and slowness and therefore add extra costs to the TCO (Total Cost of ownership).

Triggering a domino effect, poorly performing APIs prevent other APIs in the integration from responding properly. All of these factors increase turnaround times and erode the user experience (UX), hence undermining the confidence of customers and partners who rely on their systems.

Arguably more alarming are the security threats caused by these partially implemented controls. By dividing systems into independent, modular and reusable applications pieced together using APIs, we open new endpoints to the risk of cyberattacks. The exposure and critical nature of APIs - as they handle sensitive data (personal, banking...) - make it absolutely necessary to adopt security protocols to ensure that no threat will go unnoticed. These tests will be correctly run only if APIs are considered a central element of banking architectures.

Give credit where credit’s due

Rather than an overlay, an afterthought, APIs should be treated as "first-class citizens" - products of their own, not just integrations subsumed into other systems. In order to make their efficiency and safety a priority, in an API-first architecture any development project must keep in mind the end goal of API consumption.

From then on, APIs become the cornerstones of IT systems. Interconnected and omni-channel – callable at any time and by any path –, they constitute the links of a network. In contrast, monoliths are dead ends, terminal nodes, because they can be called but they do not make any calls to the outside. To enable data to move from system to system, APIs must be efficient, fast and highly secure, and this can only work if they are treated as first-class citizens.

In addition to integrating easily with other systems, APIs enable the creation of modular architectures where business capabilities are broken down into microservices - individual, self-contained, loosely coupled services. Platform components can then be added or replaced in a drag-and-drop fashion to foster innovation as the business grows and new technologies are introduced. Instead of developing new code every time new connections between applications are needed, technical teams can establish them faster by leveraging existing APIs.

This approach is also changing the way banking institutions manage their business processes. Workflows are becoming automated and native: by replacing human interventions with self-service, they improve conductivity between the front and back office and make customer journeys more complete.

Read more: Why front-to-back self-service is the future of next-generation banking

Good news, the Basikon platform is API-first!

More than API-first, API-second or API-third, it is even API-only! Now that you’ve read everything, you'll have understood that the APIs, which form the backbone of the platform, are present at all stages of the business processes and customer paths (identity verification, open banking, credit scoring, contract generation, e-signature, initiation and collection of secure payments, generation of accounting entries...). Monitoring the performance and exposure of the platform, including APIs, ensures the robustness, speed and security of the entire integration.

And it doesn't stop there. The Basikon platform is also highly customizable for two reasons. First, in addition to an extensive portfolio of "standard" APIs, it is possible to create other APIs on an ad hoc basis in order to perfectly match the needs of each client and their specificities in the way they distribute credits: it's API-as-a-service! Secondly, as the workflows are 100% configurable, they are able to manage all types of financing and adapt to all use cases (banking, leasing, consumer credit, car finance, wholesale, revolving, guarantee, factoring, Buy Now Pay Later, Revenue-Based Finance, microfinance...). Thanks to low-code technology, they adapt to the evolution of your business model without additional coding: project managers can establish their own rules and make adjustments on the fly as the organization grows and its offer diversifies.

Read more: Launching your Buy Now Pay Later offer is possible with Basikon

Revenue-Based Financing (RBF) platform : to make or not to make ? (and buy)

To learn more about Basikon's API-first platform and how its reliability, agility and security will enable a seamless experience for your internal users, customers and partners, request a demo here.