Why a new architecture is needed for open banking API platforms [Q&A]

While much literature has been written on best practices for systems architecture, the desired outcomes have been as elusive as they have been sought after. The de-facto standard for enterprise systems that exists in reality is often closer to A Big Ball of Mud.

Very rarely is an organization’s technology (the infrastructure, the software or the set of systems powering the organization) planned as the state in which we see it today. All early systems need to scale, and most companies in the growth phase don't have the bandwidth to deal with this graciously.

We spoke to Tvisha Dholakia, co-founder of apibanking.com about the state of technology in enterprises, specifically in banking, and how best to navigate this complexity to remain scrappy and cutting edge.

BN: What does a typical bank's technology stack look like, today?

TD: The closest analogy to tech systems in a typical bank is that of a rainforest -- a (haphazard) coming together of software, middleware, hardware, channels and actors. In our experience working with large and mid-sized banks (USD 20-50Bn annual revenue), we saw IT departments engaging with 200+ technology vendors for providing core and ancillary technology, and separately, upwards of 20 percent of overall headcount working in internal IT departments.

This is not surprising -- a typical organization's tech system is a culmination of business and tech decisions -- build vs. buy, building in-house, building via third-party service providers, building new products and new businesses, refurbishment and handovers, reaction to regulation, reaction to competition and industry disruptions, reaction to customer demands.

This complexity is furthered by the general risk aversion that grows along with company size, that makes decision-makers default to supposedly time-tested tech (ergo, legacy by definition), and no one ever gets fired for buying IBM.

BN: What are the risks of owning and working with complex enterprise tech stacks?

TD: Arguably the most pressing of anxieties caused by complex systems is that a lot more of developers’ and product managers’ time is spent in what would be called non-productive activities, rather than actual development or innovation.

• Longer discovery time -- Fragmentation of process and tools, poor discoverability of information and offerings, and limited observability are significant time sinks. In a complex setup, adding a new feature or resolving an issue first requires identifying all systems which need work - this is not a trivial task, especially if adequate developer support tools are unavailable. What should be completed in hours or days, takes months.
• Time spent in support -- Unexplained complexity generally entails large amounts of time spent in supporting internal and external teams who need to work together. In the absence of the necessary tooling or knowledge management, developers’ time becomes the bottleneck. According to Postman's 2023 State of the API Report, the top concerns among developers were outdated documentation, and loss of institutional memory.
• Duplication of data -- when distant systems don’t interact with each other seamlessly, information and data needs to be translated and shared, and this can be exacerbated to a point where all data and services are duplicated, significantly driving up technology costs.
• Impact on data and information security -- in an industry as regulated and sensitive as banking, working with the unknown lends a certain paranoia among the security teams when it comes to allowing development on the systems. We have encountered several instances where systems have stringent protocols for access, encryption for non-sensitive APIs, firewalls and manual interventions for configurations, etc. - which are an outcome of internal security SOPs, and which slow down development but don't necessarily enhance the overall security.
• Developer fatigue -- as timelines explode and productivity takes a hit, it naturally impacts the team morale.

And a direct implication of this on the experience for the end customer. Traditional banks are well-known for sub-par experience on their desktop and mobile applications. Complex systems give way to system-first design, as opposed to customer-first design limiting CX from the very start.

I have to emphasize here that complexity by itself is not the evil, it is at times necessary. 'Simple is beautiful' is pithy advice which may be misplaced if force-fit into large organization contexts. Sure, there are times which call for starting again from scratch, but more often, the imperative is to embrace, explain and navigate the complexity effectively.

BN: Has the pace of open banking been impacted because of this?

TD: In the decade since its advent, open banking has not played out as expected, despite the clear business case. For instance, according to Cornerstone's research report, What's Going On in Banking, over 40 percent of banks globally are either still just discussing APIs, or don’t even have them in the radar.

Bank API development has largely been focused on internal APIs, and hence BaaS tech partnership are only emerging, and in a clunky manner -- timelines for integrating with banks are extremely high -- ranging from 6-12 months on average, and requiring significant investment of time, resources and developer capacity on both ends -- bank as well as ecosystem partners.

BN: How are CIOs approaching this issue? What kind of solutions are they exploring?

As API-led partnerships are increasingly gaining mindshare and investment share of bank CIOs, there is a push towards building faster. However, the typical solutions that are being devised at the traditional financial institutions are reactive, and specific to the issue at hand, and not strategic.

For instance, if a bank is prompted to develop a certain set of open banking APIs to serve a partner who establishes a compelling business case, these tend to be specifically designed only for this partnership. The overall strategy for scaling the offerings and the future state of developer experience is largely missing.

BN: How do abstraction and developer tools fit in with this problem?

TD: System complexity requires that developers not only need to understand each system, but also the interdependencies, and how they communicate with each other.

If an organization's system is beginning to look more and more like a maze, the best course of action is to help developers navigate this maze. The navigation systems are the developer experience tools.

Developing the understanding and institutionalizing it -- making it a part of the organization's IP and ensuring that this information is proliferated, easily accessible to anyone who needs to work with it, and is architected in a manner that is easily understood and consumable by all intended audience is key to ensuring that a complex system doesn't become a painful sore in the overall functioning and growth.

This 'understanding/information', 'access', and 'architecture' come together to form what I call the developer toolkit.

Abstraction and developer tools in the banking context imply the coming together of technology, tools, processes and the operating model. This requires investment in technologies that simplify and fast-track the development process through the principles of automation and self‑service.

At apibanking.com, the key problem we're solving is helping organizations navigate their system complexity, via this tailored DX approach -- modular solutions that fit the DX requirements for each target group's experience.

BN: What would be your recommendation to enterprises struggling with complex tech systems?

TD: Depending on the stakeholder who is interacting with the technology system, the optimal experience lies on the spectrum between complete abstraction (no/low code, DIY and self-service tools) to complete exploration (looking under the hood of the car).

For external developers/API consumers -- the complete developer experience platform

External developers want to either consume a service or use the API offering to build a journey on their platform. Legacy creates high barriers to entry for this lot -- companies, at times, don’t provide enough support to deliver a great experience to partners developers.

External developers shouldn't need to understand the entire system.
Prioritizing developer experience for ecosystem partners entails investing in the right level of abstraction -- developing simple frameworks, governance and security protocols, and even reusable UX elements, that make the task of integration and application development extremely straightforward.

For internal developers -- documentation, and observability

These are the folks that are the closest to the systems. They need to completely understand them, and it's unreasonable to expect anyone to continuously hold all the information in their heads.

The key unlock is intuitive, comprehensive, and searchable documentation -- this becomes the holy grail for the posterity of the system. And to make it the most useful for developers, it needs to be maintained like a product.
There will always be bugs, issues, incidents. Diagnostics and observability are often an afterthought, but increasingly gaining prominence in the developer experience toolkit.

For internal digital and product teams -- documentation, DX toolkit

For teams closely working with system developers -- whether product managers, digital experience designers or customer success teams, there is the right balance between explaining the systems while providing the necessary tools that boost development productivity.

This creates the imperative for business/product relevant documentation and DX support -- sandboxes, low-code tools for creating mock-ups and MVPs, reusable templates, UX elements and customer journeys/workflows.

Image credit: WrightStudio/depositphotos.com