Jim's Journal

Is it time for ISO 20022 ATM Driving? Is it time to abandon ATM Driving all together?

Summary: Could an ISO 20022 web-services based ATM Terminal Handler/Driver reduce costs and accelerate innovation by consolidating applications, connections and platforms. Would bankers, ATM vendors and bank application providers get on board with such a strategy? Do we still need ATM drivers in an IOT world? One idea to help banks remain PCI compliant, maintain legacy connections but become more innovative and extensible with their ATM strategy in an open banking world.

There are a lot of reasons to change the way bank’s control and manage ATMs including the software applications driving and running on them. After all, the ATM platform is one of the few channels that continues to be both hardware and software dependent – in a world of increasingly mobile first customer engagement. As I’ve observed the ATM and Card Based banking technology space over the past ten years, it’s become clear to me that most of us are focusing on how to work around switches and terminal drivers rather than to improve them. And maybe that is what we should be doing.  Or maybe there is a better way…

ISO 20022

My hypothesis is that adopting a flexible ISO20022 protocol, Web Services based universal ATM Driver would be much more efficient rather than today’s current approaches: Implementing new API or microservices based applications that connect directly to the ATM, redundant core interfaces based on stand-alone business services or having to customize the ATM driver every time the bank wants to add a new account type, transaction or changing an existing transaction. I believe that new capabilities could be managed through simple configuration of the ISO message with downstream orchestration and integration services in a common middle tier shared by all channels.

There has always been a trend in banking software technology to abandon old channels or methods of connectivity for new ones, to become more efficient, and that is a good thing! But too often banks leave the old methods and channels in place, creating an operational and customer experience nightmare. Think about it – today’s smart ATM applications connect to the back office and third-party providers via many different channels. There are business services on the ATM for managing the cash, components and operating systems. There are APIs to connect to authorization and third-party account services providers. There are encryption services to manage RKL/HSM and PCI compliance. And there are the good old terminal drivers/handlers that continue to drive most of the basic transactions, encryption, user experiences and other legacy technology. Layer upon layer upon layer.

Today’s IOT devices bring new focus on this age-old question of how best to manage the ATM estate at a bank. Most of the new and exciting experiences in commerce/business today are enabled by network-enabled devices like our iPhones, Bluetooth headsets, smart-speakers, digital watches and then some. Should we start to think of ATMs as IOT devices? Would the industry break the legacy standards and approaches to driving and managing ATMs?  What is the better way?

Legacy ATM Driving

Most of the current terminal handling protocols today are based on antiquated ISO 8583 messaging standards that rely on brittle, bitmap-based data definitions and inflexible message formats that are a nightmare to update and configure. Why not abandon all of this for a new IOT based ATM software platform connected to the bank’s systems and payment networks via web services and APIs. One based on microservices and like the way we drive all these watches, iPhone apps, voice-based devices? I think it is worth exploring this. Consider the new API based applications that banks are developing in the mobile banking space – giving customers the means to connect to their bank the way they want to either through the bank’s mobile app or third party FinTech’s. Extending this to reworking the branch experience – why not connect to shared printers and tablet apps, rework the whole branch flow. That is the way of the future and ATMs should be a part of it. But special consideration must be made for the valuable media (cash, checks, cards) that ATMs work with. How can banks stay PCI compliant and still implement these new IOT like solutions? I think it makes sense to find a better way to do both…

ISO 20022 Simplified Yet Extensible

Consider the ISO20022 standard. ISO20022 takes a different approach – leveraging proven XML type web-services for messaging between applications. Very few legacy ATM vendors have had success with this protocol, but it is taking hold in the payments space particularly in faster payments and POS transaction processing. If you really want to dig in here is a whitepaper on the topic. Fintechs and commercial banking vendors are doing creative things with this flexible protocol, utilizing the available payload/body content to encapsulate rich data, streamline reconciliation creating downstream efficiency. The beauty of this approach is that it could keep the current application flows in place, including expensive investments in current bank operating environments without layering on yet another platform or system. In fact, it might reduce the number connections considerably. Banks would likely have to  swap out the current business services used today that drive the various forms of the legacy ISO8583 protocols (such as 912, NDC, NDC-SMI) but it would be an evolution and open up the bank to start eliminating redundant services and other custom interfaces that are to the ATM today – eliminating the complexity creating high costs for compliance, upgrades and maintenance. 

Progressive banks are implementing a smart middle tier of microservices based applications often using some sort of ESB or API toolkit. Is an ISO20022 based protocol consistent with a microservices based multichannel platform or ESB? Absolutely, but on the back-end of the terminal driver/handler with flexibility to connect to and orchestrate with many other bank and third party applications, rather than through direct, redundant connections to the ATM software. After all, the business logic for orchestrating these new transactions and the interfaces should be in a smart middle tier or legacy switch – available to all channels for a better banker and customer experience!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.