
The business and technology model for ATM networks has remained virtually unchanged since these devices were first installed. So is a new business and technology model required for the ATM channel?
The automated teller machine (ATM) is a familiar and enduring sight to bank customers looking to access their cash 24/7. In fact for the banks themselves, the business and technology model behind the automated teller machine (ATM) network has remained virtually unchanged for the last 25 years. Ever since Barclays Bank installed the first ATM in the UK in 1967, the ATM’s role has primarily been to dispense cash. Of course, today’s ATMs can offer various other services such as balance checks and statement requests, but these are little more than peripheral value-adds, exploiting, rather than advancing, the technology that has driven these machines for so long.
It can be argued that the reason that the functionality of the ATM has barely evolved over all this time is actually that the structure of the software that powers it has been allowed to stagnate.
Today’s ATM systems are universally architected using a simplistic ‘two-box’ model in which the ATM operates either as a dumb terminal connected to an intelligent host banking application, or as an intelligent client machine connected to a slave host server. Either way, inherent design inflexibilities in the implementation of these two-box architectural approaches have come to define the manner in which the ATM and bank communicate.
This makes any customization of the ATM – be it aesthetically as regards the display or, more fundamentally, the services it provides – an extremely complex, time-consuming and expensive proposition. The current two-box architectures mean that each unit has to be updated individually and in synchronization to change the service.
Due to the timing and slow evolution of the ATM software market, it is today still clearly dominated by a small number of incumbent suppliers – the ATM manufacturers – who typically supply both the hardware of the ATM and the software that controls it. These closed, proprietary legacy systems are now proving to be a major hurdle to the expansion of ATM usage.
A new wave of services and marketing opportunities
However, as banks focus on extracting revenue from untapped resources, the humble ATM is about to enter a new era of fundamental change. Recently introduced open standards are creating opportunities for banks to seek alternative suppliers for their ATM software. New applications are becoming available at the same time as new distributed processing architectures are unlocking the potential of the networks and increasing the opportunity to interact with other bank systems and third parties.
In this exciting new environment, customers can anticipate a wave of new opportunities when they insert their card into the ‘hole in the wall’. Because applications can be created and controlled in network servers rather than individual ATMs, new content can be integrated into the network quickly and inexpensively. New services can be developed and deployed without the need for specialist staff and, because each machine can be configured dynamically, third-party processing networks can present different screens and functions to the customer depending on which bank issued their card.
For banks and third-party vendors alike, this equates to a huge chunk of as-yet-untapped marketing opportunity, while for the customer, everything from car hire to last minute travel insurance could be arranged via an ATM.
How the ATM architecture has stagnated
It is only recently that the perception of the ATM has started to change. For decades it has been viewed as little more than a practical solution to the problem of providing an essential service outside banking hours and reducing queues at the counter during banking hours. The ATM existed to support and relieve the burden placed on the human teller. It was not considered an important channel in its own right. This simple business logic was representative of banks’ strategic thinking at the time, which was dominated by the high street branch as the main channel to customers.
Development was also hindered by the fact that many banks’ central accounting systems could not support 24/7 online services. These host mainframes supported online services for the branch teller network during the day and then ran batch accounting updates overnight. High availability front-end processing systems were introduced to overcome this problem and some banks outsourced the support of their ATMs to third-party processing networks. Complex proprietary operating systems in these machines encouraged the use of third-party supplied switch software.
As a result of this reliance on a handful of software suppliers, the only real differentiator between different banks’ ATMs came in the shape of the customer interface. Changing the presentation of the interface was in itself a difficult task, and one that was compounded by complex ATM manufacturer-specific codes and logic.
No opportunity or inclination to differentiate
Most early ATMs then were little more than dumb terminals, controlled by non-standardized networks and manufacturers. This meant the banks had little scope to expand the services provided by their ATMs and little inclination to do so either, given the cost involved and their focus on the branch channel.
A minority of more technically advanced banks built their own ATM applications using the ATM manufacturer’s software toolkits. In these installations, ATMs were connected directly to the banks’ online accounting systems and the service was controlled by a bespoke application within the ATM.
To make the smallest of changes to the way the service was presented required either the modification and distribution of complex data files to ATMs acting as dumb terminals, or the time-consuming updating of software in every ATM. Such procedures are hardly in line with today’s banks ambition for rapid response to competition and customer demand. Furthermore, the testing required of any updates to these complex systems has deterred many banks from making major updates to their services.
Whatever the approach, banks have become locked into inflexible two-box architectures, where the ATM acts as either a ‘dumb’ device controlled by the central switch or an ‘intelligent’ client, making requests to a slave host server. These architectures were designed in response to a simple business model using technology and networks available at the time. While they have proven reliable over the years, they are no longer suitable to today’s fast changing business climate where flexibility and a rapid response to market demands is a critical factor to continued success.
Current business and technology drivers
Despite its limited service offering, the ATM is now the banks’ most commonly used customer touch-point (over 1.5 million machines are in operation worldwide) and is a trusted and familiar device on which many people depend. In fact, if a marketing guru were to devise the ideal marketing device, they would probably come up with something that closely resembled the ATM. And yet this vast potential has been virtually untapped to date. Now, the advent of powerful new networks and machines is driving a profound transformation in the role of the ATM and self-service terminals.
As high bandwidth networks become commonplace, allowing huge quantities of data to be relayed in real time, the reliance on outdated software architecture stands as the final hurdle to the development of new ATM functionality.
The withdrawal of support for OS/2 by IBM has recently prompted the adoption of the Microsoft Windows operating system as the cornerstone for most ATM software environments. ATM providers such as NCR and Diebold have invested in Microsoft-based solutions, while Wincor Nixdorf also now offers Java-based solutions to allow other operating systems to be adopted in future. Interestingly however, these solutions, although implemented using up-to-date technology, still perpetuate the original architectural approach.
Microsoft Windows has introduced new open software standards (XFS) in the ATM allowing more radical software solutions to be provided by third party software specialists. This shift, coupled with the availability of powerful, high bandwidth networks, means that the infrastructure is now in place for banks to implement a fully distributed software architecture in their ATM network.
The emergence of the IFX message standard encompasses communications within a wide range of delivery systems (for example, branch terminals, home banking or ATMs) and the support for IFX removes the need for multiple proprietary ATM communication standards – which has acted as an obstacle for too long.
The IFX message protocol – already supported in most of the leading third-party switches – assumes intelligence in the network and removes control of the ATMs from the central switch. Banks that have historically built their own ATM applications could migrate their systems to this communications standard, enabling them to use generic tools as part of their solution.
In addition, new card technologies mean that the ATM could provide an array of bespoke services. Indeed, the opportunity for the individual to actually tailor the services on offer when they insert their card into the ATM is well within the bounds of current technology. Using their online banking portal, the customer could highlight which key services they require when they use an ATM.
Marketing and customer service drivers
The current mindset of today’s banks is a far cry from the branch-focused strategy that dominated 20 years ago. Today, internet and telephone banking are considered cheaper, more efficient alternatives to the branch network.
However, the branch is also enjoying a resurgence with new self-service machines playing an important role. And as ATMs have become more widespread – moving beyond the wall outside the branch and into bars, restaurants and convenience stores – the scope for self-service delivery that empowers the customer has increased. But to achieve the delivery of next generation services via the ATM, banks require a more flexible model that allows:
Moving away from the two-box approach
At present, the main obstacle preventing such services is the two box architecture that banks use in their ATM environments. Until recently, banks’ ATM environments were still reliant on legacy network technology, operating systems and hardware that had changed little in the past decade. However, the uptake of Windows XP and XP Embedded as support for IBM’s legacy OS/2 is withdrawn has been accompanied by more powerful processors within ATMs and more widespread adoption of high-bandwidth IP networks.
In the US, an increasing number banks and deployers are migrating their ATMs to run Windows. With the spread of more functional, enabling technology in their ATM environments, a tipping point has been reached. As the remaining pool of legacy technology shrinks, there is momentum for change. Banks are now at a point where they must seriously consider upgrading their software architecture, as well as their hardware and operating systems, to take full advantage of the service transformation opportunities available to them.
Banks require an ATM model vastly more flexible than the existing restricted two-box architecture. In addition to changes in operating systems, hardware and networks, the development of open standards over the last few years provides further opportunities. Open standards mean banks and third-party networks can now seek alternative suppliers for their ATM software, allowing a single software solution to be deployed on any manufacturer’s hardware.
Distributed architecture provides a model for the future
Modern tools and high bandwidth networks have transformed the distributed architectural approach from pipedream to reality. With such a model in place, processing and control can be located within the network where it is required. This solution goes far beyond previously proposed simplistic web-based ATMs and self-service terminals.
The IFX messaging standard is critical to this model. The existing ATM transaction authorization protocols are no longer capable of handling today’s functionality. IFX allows the bank or ATM deployer to use the same software applications and supporting infrastructure across several channels. This reduces software development cost, while enabling advanced ATM functions such as personalization and additional services to be supported and separated from the core transaction logic.
With the IFX definition providing the communication between host and ATM, an encapsulated IFX ‘kernel’ could reside in each ATM to provide a secure interface to these services. This would allow application services to be contained in network servers rather than in each ATM. These services can execute either within the ATM or the application server, as they are location-independent. Customer applications can interact with external customer relationship management (CRM) systems, home banking systems and external third-party systems if necessary to create and deliver a customized service. Within the ATM, requests are made to the IFX ‘kernel’ to initiate financial transactions with the central switch or host. This approach creates greater flexibility in service presentation to the customer, whilst maintaining a totally secure interface to financial transactions.
Implementing a distributed architecture for ATM networks could provide banks and customers with a number of benefits, depending on which distributed elements are connected to the network.
Focused promotions and services
Promotions and presentations can be customized for the individual user at the ATM rather than employing the one-size fits all approach of the past. By linking the ATM to the bank’s CRM systems, banks can offer a personalized service, creating a much higher level of customer satisfaction and loyalty. Furthermore, promotional campaigns can be focused and timed to maximize sales.
In a similar manner, campaigns could also be focused on specific locations and on particular groups of customers, just as advertisers do with bill posters. Promotions could be activated only at specific times of the day – for example, evenings at supermarkets where promotions might be aimed at the busy professional who is late night shopping.
By improving the graphical presentation of their service, banks are also better able to reinforce their brand image and exploit the potential of this frequent interaction with their customers. Banks could display promotions and adverts at the ATM without affecting the simplicity and speed of service of a basic cash withdrawal. In addition, real-time messages, such as urgent charitable appeals or seasonal offers, could attract new customers to the bank’s machines and create a more responsive image.
Third-party integration supports cross-selling opportunities
When operating across a distributed network, third-party network providers can grow revenue from their machines by allowing them to be shared by a number of banks. Rather than each ATM presenting a generic interface, the machine would be dynamically reconfigured so that when a customer inserts their card, their particular bank’s screen is displayed (possibly customized to the customer’s requirements). With a modern software architecture in place, each bank could have direct control over their own service, delivering it from their own server on the network, rather than relying on an image installed on the ATM.
A network of servers using a distributed computing model enables a complete service to be created, maintained and delivered to customers at ATMs and self-service devices in a flexible manner. Appropriate departments can control the service in a dynamic and integrated fashion. Furthermore, a simple, user-friendly interface would allow non- technical staff to easily change and update the presentation layer, thus accelerating the process and removing complex and costly technical hurdles that hamper customer service.
Ultimately, banks could integrate the ATM with other banking delivery channels and provide a flexible, customer-orientated service. Furthermore, third-party networks will be able to offer their banking customers the same level of control and customer focus as an in-house network, whilst sharing the physical infrastructure of devices.
A vision of the future
For too long the potential of the ATM has gone overlooked and unexploited, largely because most banks have relied too heavily on their ATM suppliers for software. By adopting a distributed software architecture, the many benefits highlighted in this article can be easily and inexpensively implemented across the board.
With the infrastructure now in place to kick-start a new era of ATM usage, high street banks need only to provide the impetus to drive this change through. A distributed hardware and software architecture, delivering a fully customizable service, linked through a bank’s CRM system and providing detailed managerial reports, sounds too good to be true. And yet it can be made available, right now, and is ready to be implemented with minimal expense or disruption.
As we have already seen, the benefits of this new approach can be many, ranging from a simple personalized greeting to instantaneous service downloads and online deployment of applications. Coupled with the recent technology advances made in the payment card industry, a network of dynamically configured ATMs will allow both banks and their customers to enjoy an unprecedented array of new ATM services.
Level Four is a leading global provider of test and development tools for the ATM channel, enabling banks and processors to maximize their existing investments in ATM and self-service technology. Level Four's key offering is the ATM Channel Development Suite, an integrated suite of software products that enable its customers to unlock the profit potential of their ATM networks.
Sharing the wealth
What potential does a distributed software architecture have to offer an ATM network?
The bank
The customer
Third party partners
Key facts