Latest Research On APIs & How Banks Can Thrive In An API Economy

In May, Accenture released a new piece of analysis ‘How Banks Can Thrive In An API Economy.’ The industry press has been awash with company announcements and predictions of greatness for those successfully launching an Open Banking proposition. Increasingly, we start to see more scepticism and articles describing why Open Banking is never going to realise the initial benefits that many foretold two years ago. As Bill Gates famously said:

“We always overestimate the change that will occur in the next two years and underestimate the change that will occur in the next ten. Don’t let yourself be lulled into inaction.”

 

The benefits

Open Banking will clearly have a profound effect on the industry and the report from Accenture provides a balanced view which is worth reading. A link to the report can be found below. Their summary is as follows:

“In combination with a clear and concise Open Banking strategy that offers a secure way to share data among registered service providers and third parties, APIs can serve as the building blocks for banks’ efforts to connect and re-connect with their customers. By taking advantage of APIs’ unique abilities to facilitate communications and transactions, and by embracing an API-driven architecture, banks can transform themselves to unlock new sources of business value…while banks are becoming increasingly aware of the benefits of an API-driven architecture and many incumbent banks have started developing APIs in some shape or form, the path to “success” is hampered by several factors”

The largest issue facing the industry is not a shortage of business and commercial ideas, but the successful funding and implementation of a new approach.

 

Challenges in implementation

Accenture believes that there are several areas which are challenging the implementation of APIs. Accenture lists these as:

A Reactive Start – Many banks have taken a reactive approach to API adoption. API programs cobbled together without a strategic vision, including a clearly defined Open Banking strategy, run the risk of turning into capital expenditure-heavy IT programs, with spiralling costs and limited ROI.

Legacy Systems – Many large banks run on legacy systems based on monolithic architecture and bespoke interfaces. These systems are often too critical, too risky and too expensive to replace, limiting banks’ ability to bring new products to market.

A Fragmented Approach – Without strategic steering at the senior level, API programs run the risk of fragmented implementation. An API-first approach in one area might not be adopted in another, even though both use the same delivery channel and even the same back-end platform. Multiple and sometimes duplicative development efforts in different lines of business and/or different geographies can increase expenses and reduce ROI.

 

Bringing new and old systems together

For the industry at large, the use of APIs creates a highly complex channel. As with all channels in our industry, ultimately it has to operate in tandem with all other existing banking services, and should be seen as part of the overall picture, not separate from it. While many bets will be made on the options offered by APIs, many organisations will have to integrate them into legacy services and systems. At the most basic level, it is likely that transactions generated by API requests will necessitate processing across the normal payment rails.

 

How to achieve integration

With that in mind, and given what we do for a living, it occurred to us that there is every likelihood that banks and service suppliers may end up creating yet another set of silos to test. This will further compromise the essential need to see the full end-to-end effect of changes when the technology is deployed. It will be interesting to see if the industry realises this from the outset, and avoids the previous costly approach of simply adding stubs or mocks to an already complex environment. Failure to do so will take us even further away from the goal of simplifying and automating the various process we use to deliver assurance to FIs. It will also add more cost, and indeed more friction to a development that is premised upon lowering costs and increasing flexibility.

 

Technology

APIs are superb. They allow you to exposure your features to the outside world and access services from other organisations. However, their nature can make it difficult to develop robust testing, and if you don’t control the “test system” then you are going to hit your first problem.

It may be expensive to connect to the system, or the system owner may only make it available during certain hours. In addition, the system under test might only return behaviour that is out of your control. What do we mean by this? For example, you may wish to test dropping a communication channel half way through a test. Increasingly, people do their banking on the train to and from work and tunnels tend to be signal proof! Or, you may look to identify test cases for a stolen credit card when the API insists the card is OK.

This can throw up problems as the full end-to-end transaction might react differently in a situation you have not been able to assess. The result is that you will be going to market with a system that is only partially tested. Hope is not a test strategy and, in essence, that’s the approach you will be taking if you don’t test accurately. And the expense of getting it wrong, and experiencing an outage on a new product, is huge. Equally, the need to quickly, and cohesively regression test your platform after changes becomes even more of an imperative if you’re exposing your organisation’s assets to third parties.

 

Testing solutions

The approach to innovation and testing has changed radically over the last few years but the vast majority of organisations remain stuck in a process which causes them delays, and results in launches with systems riddled with problems. The way around this is by using ‘virtualisation’, allowing you to replicate an end-to-end test of all the points in the transaction.

Virtualisation not only lets you test in isolation from the API provider, but allows you to orchestrate calls to multiple APIs entirely under your own control. You can more easily perform negative tests that the API may not easily allow, make the connection available to all members of your test team 24/7 and allowing access at zero cost. In short, it liberates you from many of the constraints, but more importantly it reduces cost and risk.

Through the use of virtualisation, you can take back control of API testing, modify the API in order to prototype, and massively scale the tests for stress and performance analysis. With virtual models and 24 hour availability you can schedule complex regression tests that run automatically regardless of how insignificant a change is made. And this is anywhere in the transaction lifecycle. When switch/migrations occur between APIs or an API release, virtualisation allows multiple “versions” to be tested in any combination, which removes the usual risks for the migration.

 

The industry is at a crossroads

According to Accenture, APIs are much more than a technology solution. To take full advantage of APIs, banks have to re-think their approach to API adoption, address technology for API enablement, consider governance for API delivery and measures to activate the API ecosystem. To do so, it is helpful to take a step back and gain a deeper understanding of what APIs are and the role they play in the banking environment, and the bank’s Open Banking ecosystem.

From our perspective, successful implementation will occur when banks rethink their approach to launching new technology. By utilising the latest thinking and approaches, banks can create a competitive advantage as they can launch new propositions faster and safer than ever before.

To read our analysis on APIs and Open Banking then you can access all of our articles on the topic here

If you want to see the full report from Accenture then click here