BankNews.com

BankNews

When Will Banks Self-Disrupt?

By David Andrzejek

I recently spoke at the Sibos conference in Sydney, which brings together leaders in banking and finance, and everyone was talking about application programming interfaces — in sessions, in hallway conversations, even at the bars when people got together for drinks.

To an extent, this is to be expected; PSD2 mandates and “Open Banking” initiatives are still rippling across the globe, and APIs — the mechanisms that let software systems interact and that enable developers to leverage data and functionality for new uses — are a central part of that.

But what struck me was that much of the API chatter was mired in a strategic gray area; some banks seem to still be focused on APIs as a regulatory compliance project, while others are only treating APIs as one part of their IT modernization efforts. Few executives and banking leaders seemed certain about how to embrace new API-based business models. Enthusiasm for bridging this gap was uneven.

For many of these banks to compete in the future, this has to change. In general, banks need to become more agile, more willing to challenge their own models, and more open to new business models with new partners to continue to thrive in today’s digital world. Here are a few observations from my time at Sibos — and some of the hurdles I believe many banks must overcome.

Bank APIs compete on two battlefronts.

For banks, APIs are major actors in two broad battlefronts: evolution within traditional banking and disruption from digital natives. Based on the conversations I had at Sibos, many banks are more comfortable with the former than the latter.

Among traditional banking institutions, it’s more common to think about using APIs to compete with one another than to guard against disruptors. Executives tend to view APIs as a way to enter new markets, geographies or lines of business — and to be sure, because APIs encapsulate modular, extensible aspects of a bank’s services via software, they are ripe for this large variety of use cases. Some corporate banks are planning to leverage APIs to get into retail, for example, while some banks are harnessing APIs to enter other geographies. Banks weak in small-and-medium business (SMB) markets can now project their offerings into different digital experiences, perhaps leveraging a larger platform where SMB customers already congregate — a tactic physical branches could never emulate.

The above examples are all excellent API strategies — but I’ve observed that many banks are not fully executing on them because they are overly concerned about disrupting themselves.

Use cases in which a bank leverages a larger platform or inserts itself into a partner’s digital experiences aren’t as common as they should be because banking leaders often fear the loss of customer relationships by syndicating their functionality via APIs. They are afraid to merely be participants in customer experiences rather than the owner of those experiences. This hesitancy and cloudiness of vision often limit banks’ abilities to execute against the more nimble of their traditional competitors and can completely undermine their ability to match the creativity emerging in the fintech space through digital natives.

While it is easy to assume PSD2 and open banking regulations are driving banks to innovate via APIs, this is not always the case. At Sibos and in other conversations I have had through my work with Google’s Apigee team, I’ve gotten the sense that regulations may actually be distracting banks by causing them to focus on regulatory compliance checklists rather than embrace the full innovative power of APIs. In markets without open banking mandates, simple competition often appears to be driving banks faster and toward more concrete plans.

Culture and focus can be as important as technology.

Compounding all of the above, several banking leaders I spoke to at Sibos expressed concern over the significant organizational and cultural changes their institutions must undergo to truly capitalize on and compete in today’s digital ecosystems. Banking IT teams are traditionally not product-centric — but APIs, as leverageable software expressions of the business’s digital assets and abilities, should be managed as products.

This means that bank IT teams need to break down their silos and become more responsive to the market. Their APIs have “customers” in the various developers who use them, both inside and outside the organization. Those developers are trying to solve problems and create innovative new services, and attracting and servicing this new constituency is not a competency inside the bank.

Additionally, though some banks want to open their payments system via APIs to enable additional distribution, they sometimes encounter challenges and blockers because they rely on the same underlying batch legacy system. “Digital” expectations are higher than what legacy functionality can deliver, and several bank leaders highlighted the need to upgrade underlying payment hubs or core bank systems—a process that, as one technologist in attendance put it, “amounts to ‘heart surgery’ for a bank…. very risky!” A couple of the banks I spoke with were considering augmenting older batch/mainframe backend systems by building new “greenfield” functionality in the cloud via microservices-based architectures.

Commitment is key.

While it was very encouraging to hear so much discussion around APIs, it would have been more encouraging if more of the discussion had focused on leveraging APIs to unlock new business opportunities rather than to check off regulatory requirements or triage legacy systems.

Few banking executives are issuing unequivocal mandates for their teams to go to market with APIs; Gottfried Leibbrandt, CEO of SWIFT, is one of the exceptions. SWIFT has made a huge public commitment to its API strategy, looking to both modernize the global interbank payments system and also standardize APIs across banks. “We envision enabling most of our existing services through API calls rather than the current, often bespoke access ways,” he said in an interview, adding, “And on top of that, you can think of lots of new services where you can get the information immediately.”

Bank executives could learn from this example and push their organizations with an aggressive strategy to compete in the fully digital API economy.

 

David Andrzejek leads go-to-market for Verticals and Ecosystems at Apigee, which was acquired by Google in November 2016. David helped launch Apigee’s data-driven security products.

  • Sign Up

  • Categories

  • Archive

Software: Kryptronic eCommerce, Copyright 1999-2019 Kryptronic, Inc. Exec Time: 0.066738 Seconds Memory Usage: 3.799858 Megabytes
Kryptronic