What are the unique challenges and considerations while conducting Performance Testing for Payment Switches / Applications?

INTRODUCTION

PERFORMANCE TESTING checks the speed, response time, reliability, resource usage, scalability of a software program under their expected workload. The purpose of Performance Testing is not to find functional defects but to eliminate performance bottlenecks in the software or device.

Performance testing is always been an integral part of information technology sector. It becomes even more essential when it comes to critical areas such as banking, stock market, e-commerce, online ticketing services and fintech. These are the areas wherein poor system performance can restrict potential revenue of the organization; ultimately causing real-time and non-retrievable – financial as well as reputational losses. A tiny issue in the system’s performance can lead to huge financial losses.

To avoid system performance related direct or indirect losses, organizations have become cautious about the health of their applications, systems and infrastructures. Over the period of a decade, the demand for performance testing have been increased exponentially. And because of higher demand, performance testing itself have become an individual domain. Result of which, a lot of relative tools and expertise have got introduced.

But there are still some areas, where performance testing is not popular. In our todays blog we will talk about one of those areas and we will try to understand what are the reasons and challenges behind it.

Here I am talking about Switching technology. As we already know that it processes any card-based or payment transactions initiated at various acquiring channels like ATM, POS, e-Com, IVRS, mobile/internet banking etc.
Switching technology is one of the important areas of FinTech and it’s been standardized and accepted globally. Some banks are having their own switching environment and some of them are going for a processing platform i.e. shared environment. But all in all, todays fact is – none of the bank can survive without switching technology. Day by day the number of switch-based transactions are increasing enormously. This switching domain can also be described as 2^nd largest and critical areas in banking sector after core banking system.

In spite of being such an important entity, the performance testing for this domain is yet not grew as expected. The challenges are quite interesting to know.

CHALLENGES AND CONSIDERATIONS

1. Complexity in Variety: Switch technology is a combination of multiple service areas, and solution of each service area varies from another. It means a performance testing solution developed for one service area doesn’t remain suitable to another. So, each service area needs a distinct solution and because of this, the scope to develop a performance testing solution for switch becomes vast.E.g. One service area is debit card management system and another is transaction authorization. Both the service areas are equally essential but the solutions are totally different.

Likewise, regarding load testing of transaction authorization – a solution to create automated load of ATM transactions is different than that of POS or e-commerce transactions.
Similarly, to validate performance of EOD activities a different solution is required to create a load.
Hence there is no single tool available in the market which can be termed as a single standard solution to conduct performance testing for all the service areas of switch.

2. Proprietary designs and their distinctiveness: Payment Switch is been a perfect competition market since long time. Many companies have launched their proprietary products and working hard to find creative technical solutions, in order to attract clients and stay-fit in the market.Considering this fact, we have a lot of Switch products available today which were developed to serve a common purpose of the industry. However, each of the product is distinct because of three facts – product architecture, solution and technology.

Even though all the companies have designed their products considering the norms of Payment Card Industry, internally each of the product is designed in its own distinct way.  Because of which a solution developed for one product cannot be replicated to another product from a different company.

E.g. Measuring a response time of any activity or transaction is one of the parameters in performance testing.
During load test suppose a delay is been observed. Then to identify the cause of that delay, certain check-points are applied internally on modules/procedures of the Switch. And this can be achieved with the help of expert solutions, by making some technical interventions inside the Switch system. These technical interventions become system specific to that particular product only, which cannot be replicated to another Switch of different make.

3. Exclusive services lead to unique solutions:Each switch is unique in its own way! Even if two different banks from same country are having their switch of same brand, both the switches will be implemented with different solutions because of the dissimilar requirements.Banks have started focusing on how to stay updated with the market. Keeping customer satisfaction in mind, launching innovative ideas and taking experimental approach have become common.

Looking at the demand in EFT, cards and payment domain, banks are trying to provide USPs by availing products or services uniquely in some or other way.Result of which lot of customizations are happening locally to cater variety of requirements or enhancements.

Even if a same bank is having presence in multiple countries, they are required to maintain a different switch solution for each of the country. This is to cater the mandates applied by national and international interchanges. Here the mandates play the role of differentiator. Hence a common performance testing solution cannot be applicable even if multiple banks having same type of switch product.

4. Product trust and system customizations: We saw above four direct challenges which occurs while conducting performance testing. But there is one indirect challenge which is also equally responsible. This indirect reason is nothing but the blind product trust which customers are having, due to the goodwill that product companies are having in market. This challenge is not the one which occurs while conducting performance testing but, it has definitely reduced the requirement of performance testing in overall market.To elaborate – During product finalization phase, bank validates if the necessary requirements are met or not. Product company also makes their customers satisfy by providing accurate solutions and value adds, by doing multiple customizations in standard product. These customizations can be at program, solution, module or architecture level.

But due to such numerous customizations the system becomes different than the standard product. It becomes more complex, which can cause impact to systems performance.
Studies have been reported many incidents so far, wherein a performance of final implemented product is observed as a degraded one. Here we need to understand that, to meet certain performance norms a system has to undergo some benchmarking processes. Benchmarking is always performed on standard product and not on customized versions of it.

And the problem statement is, after doing all the customizations banks still believes that the system will perform as per their requirement. However, during initial stages system may work as expected but as the time flies, number of system users, transactions per second and other system activities start increasing. Result of which, slowly and gradually performance related issues start impacting the system and ultimately to the business.

As per my understanding, any bank should conduct performance testing at least on below events –

• Implementing a new switch
• Migration
• Version upgrade
• Rise in transactions, activities or users
• Any change at product architecture

5. Absence of universal solution:Till today there is no single solution, which can automate the entire process and serve the purpose of end to end performance testing. However, it can be possible by using multiple tools to cater each of the service area of Switch.  For example, to create load on UI based applications, we can use Load runner, JMeter etc. But these applications cannot be used to generate transaction related load, and for which we have to use domain specific applications like FINSIM, NeaPay etc. which comes with hefty prices.

We have already discussed about the challenges to conduct performance testing in reason 1, 2 and 3. These challenge remains unchanged when it come to development of a new tool that can be a universal solution of for this domain. But it is also not impossible to develop such a solution. However, developing such solution is a huge scope looking at the demand of this niche market.

Considering this fact of demand v/s market structure, chances of arriving universal solution within near future are very minimal. But having said that, it doesn’t reduce the criticality of performance testing of Payment Switch application.

Before concluding, I would like to summarize this topic as follows–

• Although a standard Switch product catalog defines the suitable system performance, it is still important to conduct Performance testing.
• Conducting end-to-end performance testing for all the service areas of Switch is a challenging activity.
• There is no standard product available in market so far, which can be used as universal solution.
• It is very much possible to conduct performance testing to measure performance of all the service areas using combination of solutions.