Banking 2.0: Navigating the Chaos

Until recently, retail banking has been a comparatively stable, if complex, business. One might say it was a period of evolutionary rather than revolutionary change, with a relatively small number of incumbents dominating markets in which regulations and economic factors produced relatively few truly radical new initiatives. Change could be slow, innovations far apart.

As new digital technologies have gained mass adoption, the landscape has changed. Mobile apps, cashless systems, and many other advances have changed the stakes, relatively quickly — just look at the number of branches closing as more customers do their banking on-the-go in purely digital environments.

On the 13th January, the new Open Banking (OB) regulation in the United Kingdom came into force, mandating compliance with the second Payments Service Directive (PSD2). This is a significant development in the new period of rapid evolution in banking. As regulatory changes unroll alongside rapidly evolving technologies, the range of participants shaping financial services is likely to expand and the pace of disruption is likely to accelerate.

Specifically, the new OB/PSD2 regulations are encouraging new companies to enter the market by mandating that previously-closed banks provide system-to system-interfaces, i.e., application programming interfaces (APIs). These APIs enable companies vetted and approved by the Financial Conduct Authority (FCA) and permissioned by account holders to access transaction data and request or initiate payments.

Put another way, in the past, customers of a bank could only expect the bank and its immediate partners to offer useful financial services using a customer’s personal information. Now, those apps can come from a much wider range of developers, increasing the likelihood of new innovations to help people manage their finances.

The Challenge: Bringing Banks into the Digital Age

Though OB/PSD2 presents many potential benefits, especially to consumers, it also creates potential challenges, especially for many banking incumbents that face new competition and ways of operating. To navigate the chaos, these banks must often negotiate the following steps:

• Continually probe the evolving landscape, constantly looking for new opportunities. Because banks no longer possess monopolies on certain data and functions, the nature of how organisations build services, engage with ecosystem partners, and generate personalized value for customers has changed.
• Once an opportunity has been identified, rapidly assess its impact and decide whether to pursue it.
• React at speed, faster than competitors, to exploit the opportunity.
• Learn from their first move and iterate the product.

At a foundational level, the limiting factor in this process is how quickly an organisation can build new interfaces between software platforms, i.e., how well it can leverage APIs.

Banks are often hampered by slow-moving systems of record, shackling them in ways that fintechs, challenger banks, and various other digital natives aren’t. When they think of APIs, these banks may think of simply exposing existing services for integration.

This perspective limits the value of the data, both for internal innovation and for outside collaborators. Consumers of these APIs will likely find them difficult to work with, weighed down by a jumbled back-catalogue of exposed legacy services of different styles and formats. This “inside-out” approach, defined more by what IT says is already available than what partners and customers demand, may result in poorly-defined, ineffective interfaces — and thus in little-to-no innovation.

The challenge faced is how can an organisation operate a multi-speed IT environment to meet the requirements of the new market? How can a bank have its legacy cake and adopt the speed of new challengers to eat it?

The Answer: Empowering Developers and Going “Outside-In”

The good news is that many organisations already have the answer to this problem. The OB implementation explicitly calls for an API management platform to manage the interfaces created for compliance with OB/PSD2. These platforms help banks separate the systems of engagement (e.g. websites, mobile apps, system to system communication etc.), from the core, internal systems of record — but they also provide insights into how APIs are being used, tools to facilitate developer access to and understanding of APIs, granular control over permissions, and a host of other features. That is, API management helps the API to be not merely a crude connector but rather a product that helps developers move faster and create innovative services that help people do more with their finances.

Moreover, robust API management gives organisations the visibility and control to move beyond “inside-out” perspectives, shifting to an “outside-in” view that focuses on the needs of customers and applies design thinking and product management best practices to meet customers’ shifting needs. In this way, the APIs are mechanisms for not only exchanging value in digital economies but also gaining the insight to seize opportunities and develop customer obsession.

Making the Move: Executive Participation is Crucial

In my experience working with enterprise clients in my role on Google’s Apigee team, I’ve found that active executive sponsorship is often the most important differentiator in digital transformation. In the case of OB/PSD2, this support will likely be mandatory if an organisation is to expand its API program from mere open banking compliance to true innovation.

Executive sponsorship can drive progress in several areas, notably:

Taking an “outside-in” approach to API products and design

• Following the Amazon API mandate by Jeff Bezos, which arguably laid much of the foundation around which Amazon’s future expansion was built, leaders should emphasize that API products are central to the vision and direction of the organisation.
• Executives can bring the voice of the customer to the technology team by embedding product management in IT.
• Leaders should focus on the customer’s needs, not simply what can be provided from the existing IT service catalogue.

Driving the acceleration of delivery through Agile practices beyond the API program’s current scope

• Executives should ask the API the team where they are held back and help break down those barriers. For example, how can a team be truly nimble if the team has to comply with a monthly release cycle?

Defining what success looks like and communicate it when it happens

• Leaders should define metrics or key performance indicators (KPIs) that are clearly linked to the vision and objectives of the organisation, not simply IT-driven metrics.
• Executives should align on how often those metrics will be measured and how progress can be routinely communicated.
• The business shouldn’t be ruled by numbers alone. Leaders succeed when they find success stories, happy teams, good outcomes, and other qualitative factors to complement more data-driven KPIs. The power of these stories, especially if told by people outside the program, can be immeasurable.

All of these steps require an active and involved sponsor to set a clear direction and definition of success, then support and empower the team to achieve it. Coupled with the existing API platform and the team’s skills, these steps can mean that the seemingly unattainable goal of operating at Internet speed and competing with startups may be much closer than it appears.

[Looking for more insights about digital transformation? Check out Apigee’s new ebook The Digital Transformation Journey, and explore Apigee Compass to assess your organization’s digital readiness.]