As part of the recent migration programme I was on, a significant part of that programme was to migrate and upgrade the ATM estate for a UK Banking group. The ATM estate had to be upgraded due to its age, outdated communications, and the need to ensure that compliance to PCI and scheme rules. Two thirds of the ATMs were actually replaced and the remaining third upgraded to latest PC cores and software.
The estate was migrated from the Bank’s Base24 classic system to the service providers Base24 classic system for ATM acquiring with the authorisation being managed by Base24 EPS fronting the issuer systems.
What became obvious to me as we managed the associated developments and rolled out the service was that with modern ATMs, an IP network, modern ATM Windows based software and open systems protocols, managing ATMs on the central legacy platforms, like Base24 Classic, is no longer aligned with the distributed network connected world which exists today.
Our legacy systems are based on a single central system architecture where all communications were sent from the ATM to that system, this included the financial requests and the ATM status messages. It was the responsibility of that central system to know the status of the devices within the ATM, control the transactions that could be executed based on those the statuses and raise alerts for those status events on its error log, as well as dealing with actual financial requests. Within the Base24 Classic architecture these responsibilities were executed by the device handler.
ATMs today are connected over IP networks so can send very detailed status information to dedicated servers using standardised network management protocols (SNMP) and those dedicated servers directly run alerting and event management systems that will deploy engineering resource, update statistics, monitor event resolutions, control spares stocks, and directly notify business operations support.
ATMs today will modify the services offered dependent on the status of their devices, e.g. if a receipt printer has failed then the screens that offer services that require receipts will be dynamically modified to remove that option from the screen without any need for the central system to be involved. So no transactions that require a receipt will be sent for authorisation.
ATMs today will ‘self heal’ for minor problems, e.g. a receipt jam event will trigger a series of actions to clear the jam and will thus, in most cases, be corrected without the intervention, so error statuses can be very temporary.
So essentially there is no longer any need for a device handler to ‘manage’ the device status, the device handler needs only to manage the financial request and route it to the card authentication and authorisation components and return the approval or the decline, the ATM can be ‘trusted’ to manage itself.
With the IP network the ATM is in a truly distributed environment so can connect to specific servers, for specific services, the financial transactions can be handled by the Base24 system, the ATM status can be handled by the event management system, the security is managed by the security server, the ATM software, configurations and screens are managed by the remote management server.
So my conclusion is that there is no longer any need to consider that the ATM is a ‘dumb’ device, ATMs have evolved and the connected networks, which the IP revolution has provided, means that the ATM device handler is now an anachronism that needs to be de-scoped. I am sure that there will be many ATM estates that will be getting upgraded to replace out of date, and expensive to maintain, hardware that is not compliant with new security and scheme standards or is being migrated to service providers, this will be the time when, rather than just continue with a like for like replacement, the actual role of the device handler should be seriously considered and the unnecessary complexities of ATM status management removed.