Blog article
See all stories ยป

Balance the Risk and Cost of Testing in Banking

A lot of things about banking software hinge on how and when it might fail and what impact that will create.

This drives all banks to invest heavily in testing projects. Traditionally, banks have been involved in testing software modules from end-to-end and in totality, which calls for large resources. Even then, testing programs are not foolproof, often detecting minor issues while overlooking critical ones that might even dent the bank's image among its customers.

So, the decision on what to test and how far, is a tricky one. However, experience shows that a risk-based testing approach is well suited to banks' testing needs, as well as their pockets.

While the technicalities of banking software testing, including automation testing, performance testing, load testing etc. appear complex, a relatively simple risk-based testing approach may be employed to identify and prioritize the areas of testing focus .

Risk-based testing follows a simple principle: It determines the impact of software failure on the bank's business, and recommends that project managers carefully attend to those modules where there is high business risk.

The next thing is to identify the most critical business areas of the bank. It seems logical to pinpoint the business areas earning the highest revenue, but that might not actually be the case. Consider these situations:

A module/sub-module furnishing wrong information to the central banking agencies of concerned geographies.

The damage to the bank's image when retail customers are updated with wrong information over Internet banking (or any other channel).

Long queuing time at ATMs due to poor performance testing.

High downtime of banking software across branches.

In such situations, risk-based testing gives the best results by according highest priority to projects involving regulatory reporting and compliance. Similarly, high priority is given to those modules/ sub-modules of bank software, which impact customer communication across unassisted channels like Internet / mobile banking.

On the other hand, lower priority may be given to software modules which fetch considerable revenues, but are low on risk.

Testing is generally executed by a dedicated testing team; however, risk-based testing calls for brainstorming and discussions with business / marketing to decide what is to be tested and on what priority.

To sum up, risk-based testing is that tool, which when used effectively after involving the concerned people in marketing/ auditing/ reporting etc., is certain to bring down a bank's testing costs. 


Comments: (2)

Ketharaman Swaminathan
Ketharaman Swaminathan - GTM360 Marketing Solutions - Pune 27 July, 2015, 10:30Be the first to give this comment the thumbs up 0 likes

Nice post. Risk-based Testing is indeed an idea whose time has come. From personal experience, reference data poses another very high-risk area for testing. A leading bank implemented a new software for cross-border payments. The software expected 11 digit BIC code whereas the old reference data fed it 8 digit BIC code. As a result, thousands of messages ended up in the repair queue. With just hours to go before the scheme cutoff, this caused tremendous tension since the bank faced the risk of missing its payment commitments to counterparties and having its solvency questioned, especially in the days of GFC when banks were turning insolvent for other reasons fairly regularly!

Matt Scott
Matt Scott - Fiserv Inc - London 29 July, 2015, 16:46Be the first to give this comment the thumbs up 0 likes In past experience I have seen banks take a variety of approaches to test - each with different degrees of success. However, the trend seems to favour the brave few that invest in automated regression test environments - which enabled them to test (and apply changes to) their environment much quicker - and much broader scope than traditional manual testing approaches. It does require higher upfront investment but will reap rewards for years to come.