Banking with APIs 101

There was a time we used to communicate with the bank over the telephone or by paying a visit to a local branch. Every bank product or service was hosted in internal banking platforms built as technology monoliths, and the entire value chain was the bank’s private property. It was until recently unimaginable, that banks would share any of their core assets for the benefit of a third party under the imperative of enhancing the financial lives of their customers.

This imperative however has now taken shape following newly released open banking mandatory regulations such as PSD2. The ‘closed banking’ architectures are radically shifting towards open models whereby the monoliths are broken down into small pieces and exposed into the open. Virtually everything the bank does can now be marketed in packages as if products and services were Lego parts.

Communication over the phone is no longer necessary thanks to open banking and APIs (Application Programming Interfaces), pieces of software allowing seamless interaction between clients and banks. Not only retail and corporate clients, but an entire ecosystem of internal stakeholders, software suppliers, brokers, asset managers, fintechs, etc. may now benefit from business models shaped around open banking and alternative ways of generating revenues.

But what are APIs essentially for? APIs enable communication and data exchange between clients (data requesters) and servers (data holders) in a secure and consistent manner. Applications and data being unbundled in modern architectures, the bank is now requested to share data under open banking regulations. In other words, the most valuable asset the bank possesses, has to be openly and securely shared. APIs can fulfil these needs in the most effective manner.

Banks do not of course need to expose all sorts of data, only to provide access to the specific information needed or required. Besides, when those data belong to clients, they always have the option to decide where and how their data are used.

To fulfil the promises and requirements of open banking, APIs are undoubtedly the best technological fit. This is a game changer for banks, placing technology as a key driver of the business strategy and a true enabler of value differentiation. Conscious of the strategic implications of these new regulations, banks are building innovative business models around the open world, going above and beyond being compliant.

Development portals

APIs can be built within dedicated banking frameworks called development portals. Both APIs and development portals have existed since long, but it is only recently these have made the headlines in the banking community. The main objective of these portals is to allow an easier and smoother engagement with any third parties banks expect to partner with.

Capabilities of mature portals include exhaustive and accurate API documentation in several languages. Among these documents we find for example the so-called ‘swaggers’, when the bank exposes their data in RESTful APIs. Swaggers are interface contracts signed between the third parties and the bank which describe the governance rules of the API, including definition and properties of exchanged data.

Portals offer a wealth of resources from software development tools to facilitate APIs creation and deployment, to tutorials, code samples, training videos, interactive roadmaps, etc. all intended to provide essential development and operational support to respond to various requests such as how to use the ‘sandbox’ environment, queries around testing of the APIs, etc.

Additional features may include a space dedicated to engage with third party communities, especially developers. These spaces are meant to create a truly collaborative environment and are used to launch and host community events, discuss innovative ideas, raise issues and challenges, etc. Great experiences when interacting with the portal are crucial to attract and secure a talented pool of developers.

The enrolment process for developers follows a common pattern, requiring sign up and registering of the calling application and mandatory testing in sandbox environment against the chosen API/s. Upon successful testing, the bank grants approval to go-live. While some banks do not take charges in development and testing phases, fees are applied when going live. Pricing largely depends on developer’s profile and the nature of the services used.

Perhaps the most useful feature of portals is the APIs catalogue. This catalogue lists all the services, remember, the Lego pieces which can be accessed from the outside in a secure and consistent manner. Services listed in catalogues depend on the specific operating business domain of the bank and its intended APIs beneficiaries.

API catalogues

Though catalogues are bank-specific, similar services can be found in most of them for banks sharing geographies, business activity, or type of clients. We are also witnessing the adoption of common development, communication, and security standards for listed services, even if a wider acceptance of standards across geographies is yet to come.

Clustering services found in catalogues across a number of banks in a simple fashion, we may come out with the simple and intentionally far from exhaustive list. (See below). APIs name are usually self-descriptive of the function they perform. Similar names are also found across different institutions for APIs performing a same function.

Accounts APIs:

· Account information

· All accounts information

· Account insights (age, solvency, tax information)

· Account transaction notification

· Account banking statements

Payments APIs:

· Payment status

· Payment initiation

· Payment confirmation

Banking products APIs:

· All personal banking products

· Loan affordability

· Loan evaluation (returns loan terms, rates, monthly payments, etc.)

· All loans granted

· Customer collaterals

· Mortgage calculator

· All payables and receivables

· Cheques images retrieval

· Cards points redemption

· Securities search and analytics

· Securities pricing and structure

· Trade transaction execution, post-trade status

· Foreign Exchange rates

· … /…

Location APIs:

· Branches location

· ATM’s location

· Book an appointment at a given location

All these APIs can be exploited by third parties for a variety of purposes in creative new ways to generate revenue. Banks may equally envisage new partnering or servicing models with third parties. Finally clients may be provided with additional resources and tools making their financial lives easier. One can imagine the sky is the limit in this space.

APIs design and banks

In most traditional banks, existing APIs were designed prior to open banking. Due to the large number of constraints IT projects frequently face, these APIs were created with a very specific purpose in mind and did not always qualify as eligible for open banking. Extensive rework was required to fit them with the right design elements for being exposed to external third parties.

In line with published standards and guidelines, more rigorous security criteria, functional enrichments, and a comprehensive review of data accesses and permissions, were usually involved in these revamps. In most instances though, brand new APIs were necessary.

Functional richness showed itself as a fundamental aspect to ensure re-usability and scalability of the API. Security requirements were equally critical. Gateways, unique and secure omni-channel access points to internal banking systems were deployed. Open standards authorization protocols such as OAuth were adopted. Under this protocol, authorization tokens are exchanged between clients and authorization servers which allow or deny access to requested banking data.

Additional non-functional requirements such as APIs protocols (metadata sent for communication purposes), and payloads overhead (actual functional data exchanged), were proven to be important technical requirements to consider in APIs design.

In every mature organization, the API product manager is now a key role in its own right, holding responsibility for design, evolution, and maintenance of an API or a set of APIs bridging the space between the now unbundled banking services and the open world.

Value creation for banks

To create value through APIzation, banks have pursued implementation steps and deployment models already put into practice by other industries. The basics are defining vision and strategy, follow any existing best practices, implement and actively monitor strategies, and enlarge the client base while strengthening relationships with partners, especially developers. The most difficult parts yet remain identifying value creation opportunities and defining the revenue generation model.

Monetizing the strategy usually entails gaining a large number of adopters. In this regard, API usability is crucial to future proof scalability. The purpose of the API and its target audience need to be then carefully thought-out. As we have seen in the past few months, some unsuitable APIs have been deprecated or versioned several times.

Different strategies may be devised according to client segmentation criteria and the specific governance model of the strategist. Importantly, innovation value is not limited to revenues: customer experience, streamlined processes, reduced costs, etc. have to be factored in as well.

Challenges for banks

Design challenges lie ahead for institutions still relying on legacy data-providing applications. These applications make APIs implementation a tedious undertaking yielding at best suboptimal results. Fully digital banks and their ecosystem of partners on the contrary, are already reaping the benefits of open banking and progressively grabbing market share.

As in all things technology, standard open banking frameworks and regulations would facilitate widespread creation of larger and cohesive open ecosystems. The current fragmentation of initiatives launched across the world could thus be avoided. This would eventually result in increased competition we could all benefit from. Bad news is that at a global scale at least, this is very unlikely to happen anytime soon.