In May, Accenture released a new piece of analysis entitled ‘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.”
Open Banking will clearly have a profound effect on the industry and the report from Accenture provides a balanced view which is worth reading. 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 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.
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.
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 my 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.