Bank testing: automation alone isn’t the magic bullet

At two conferences I’ve attended recently many discussions have focused on the opening-up of the banking market by regulations such as PSD2 / Open Banking and the Open APIs which support them. Indeed, some presentations have looked at the strategic imperative for banks to remain relevant to their customers’ lives and businesses by their creation of new ecosystems involving multiple third-parties.

Beyond this are further payment-specific developments such as SWIFT gpi, P27 in the Nordics and the strategic review of UK retail payments by Pay.UK. Progress and innovation in banking is clearly becoming more complicated and there are question marks over whether the project teams and associated testing teams are able to cope with the demands of the need to layer new payment technology (including APIs) on to old creaking legacy systems.

My experience at the events was that whilst due consideration is being paid to new technologies, new propositions and opportunities for partnership with fintechs, little attention is being paid to how the new systems, infrastructures and ecosystems will be tested prior to implementation. And this despite recent experiences in banks such as Lloyds TSB and RBS whereby damage was caused by them getting the testing of large projects wrong.

A quick answer to the testing issue might be to increase the amount of automation, but then:

• there’s no point in simply automating a bad manual process, as it just becomes a bad automated process
• the true benefits of automation - increased efficiency, lower cost, greater assurance from more robust results etc - won’t be achieved if the testing concerned is based on siloes of separate modules and systems. Indeed, it may be impossible to even consider testing automation if everything to be tested is so separate.

The complexity of the environments that banks now operate in determines that there has to be more than just automation. Banks need to be able to use state of the art testing technology that is as sophisticated and technically advanced as the new systems and ecosystems they are trying to create.

The example of a global manufacturer comes to mind; they may be able to automate different parts of their operation but the best way to do that is to have all of the components in one location so the whole thing can be automated as one continuous unit. Through the implementation of assembly lines the advanced car-makers have brought everything together into a continuous, highly automated and unified production line. Banks need to have the same type of thinking regarding their testing.

Allied to this point is the importance of rationalising the number of systems comprising a bank’s payments infrastructure. Indeed, one global bank recently mentioned a desire to consolidate from a payments infrastructure of c.90 systems to around 8.

These and other issues regarding testing are covered in a recent white paper, ‘Payment System Assurance – Reducing Risk Through Effective Testing’, produced by Finextra in association with Iliad. The paper is available here.