Many banks are pursuing ATM replacement strategies to move to the latest Windows-based ATM applications and take advantage of a wider range of customer service options and branding opportunities. However, the move to Windows introduces unforeseen problems that are causing banks to rethink how these applications are deployed after suffering an overall drop in network stability. Rollouts of the new Windows-based ATM applications have not been nearly as smooth as expected which is starting to cause concern in the industry.

The changing ATM landscape
From the early 1990s onwards, after the original OS/2-based ATM software technology had settled, banks enjoyed reliable ATM networks. The applications were stable and software updates were rarely required. The architectural model that prevailed meant that the configuration data that gave the ATM its “personality” was held in the central host system and not in the ATM itself. Most of the bank’s testing was not testing the ATM application on the ATM itself (as this was deemed stable), but centred around testing the terminal-driving systems that the ATMs connected to, and their subsequent links to external networks such as VISA and MasterCard, who regularly mandated upgrades.

Because of this, over the last 20 years customers have got used to thinking of ATMs as high availability machines and so feel significantly inconvenienced when they see an ATM out of service (sometimes with a decidedly low-tech piece of A4 paper taped to the ATM bearing the bad news), or worse still with a “crashed” ATM with an embarrassing Windows error message displayed prominently across the screen.

Indeed, following the move by many banks to Windows, empirical evidence suggests that the overall stability of ATMs on the high street has suffered and network deployers have quickly found that the volume of testing required to deploy stable ATM software is increasing exponentially. Why is this? Previously, only one simple interaction between the ATM and the terminal-driving system needed testing. In the new scenario, the application itself, as well as every interaction between all applications in the ATM software stack, must be tested to ensure the stability of the ATM. Effectively the entire cycle for deploying ATM software in a network must be rethought because of the move to Windows.

Banks have found that a full, thorough regression test could take two to three months to execute. The increasing pace of new software releases from vendors means some banks face an average of more than one release per month (consider software releases form all manufacturers of software resident on the ATM, including Microsoft security updates). In this scenario something has to give, or stability, and ultimately customer experience, suffers.

Drivers for a new testing strategy
The first driver for change is the shift to open standards. As OS/2 based ATMs are being replaced with Windows machines, virtually all banks are choosing to synonymously take advantage of the new XFS standard. This standard defines how any Windows-based applications can communicate with ATM peripherals like card readers and PIN pads. In doing so, it has served to decouple the ATM application software from the hardware. Inevitably, this move is in the interests of the end-user bank or processor as open standards and increased competition in the ATM software market will help to unblock the lack of recent software innovation in the ATM channel, and ultimately commoditise the market for ATM hardware.

However, open standards also introduce more points of integration, between different components and potentially different suppliers. As the number of different “moving parts” increases, banks face bigger integration risk which increases testing pressure. Furthermore, the new Windows ATM product solutions are largely Windows rewrites of the existing applications that were stable under OS/2, and so are still relatively new, with a comparatively frequent release cycle.

Secondly, there are now multiple applications running concurrently on the ATM, causing potential stability issues with interoperation. As banks have sought to derive business benefit through investment in modern, Windows-based ATM hardware and software platforms, so the complexity of the software running on the ATM has increased. No longer is it just a single application resident on the ATM, but new applications such as anti-virus clients, software distribution agents and monitoring software have been added into the stack making the device more intricate and increasing the number of points of failure.

Finally, when you consider the frequency of security hot-fixes, critical updates and service packs that need to be applied to the Windows operating system to protect it from harm, it becomes evident that the bank needs to dramatically increase its volume of testing to make sure its ATM network functions effectively.

The solution
Banks deploying Windows-based ATM applications have started to move from the early-adopter phase to an early majority. Those who deployed these applications in the early years were sold on the vision of open standards and Windows serving to lower their hardware costs, and deliver the sort of functionality that business heads wanted to offer at their number one customer facing touchpoint, the ATM.

The most forward-thinking banks had considered the risks as well as the benefits involved in moving their ATMs to the Windows platform, and sought a platform to automate the testing of these ATM applications.

Automated testing brings a number of benefits:

• Testing can be conducted automatically in software by providing a simulation of real ATM hardware combined with a comprehensive test harness and reporting engine
• Reliance on manual testing cycles (teams of people repetitively testing thousands of ATM transactions with real cards) and manual reporting can be eliminated
• Less physical hardware is required
• It is possible to test every permutation and combination of fault in an automated fashion. Often tests can run overnight, rather than require man-months of manual testing, meaning that projects are delivered more quickly
• Software problems can be identified and rectified at a much earlier stage before deployment

Overall, those who sought to automate the testing of their Windows/XFS-based applications have been able to track and resolve faults earlier and enjoy a more controlled rollout process to customers in the high street.

In conclusion, the move from OS/2 to Windows as the ATM operating system is not proving as smooth as banks and processors had hoped. On the face of it little had changed, but as the rollouts progressed they faced a realisation that the whole nature of the software deployment cycle would be altered with the migration to Windows. The capabilities of Windows on the ATM, coupled with the commercial benefits of open standards offers the potential for deployers to realise the business and marketing capabilities of the ATM, but banks and processors should not overlook how these applications need to be tested if they want to keep their customers happy.