I had an interesting conversation with some folks in the standards community about this today. Many people thought that Web Services are over kill for the ATM environment. I sat back and thought about it for a moment, what I came up with is... Heck ya, we could use it on ATMs. So a common pitfall that technologist and architects fall into that debatable dialog that some of the time does not occur. Could I implement this or SHOULD I implement this.
From my perspective coming from the banking arena, it is advantageous for banks to move to the web service stack. It has never been easier (at least in theory) to move to this technology. Now that a good percentage of the ATMs are no longer using the legacy SNA protocol which was replaced by TCP/IP.
From a business perspective banks have been wanting to revamp the ATM functionality for years. Many banks see the ATM as an opportunity to Cross and Up Sell services. Imagine walking up to an ATM and being able to order checks or maybe change your address. Big efficiency gains, reduction of labor on the bank side and the customer feels empowered. This is especially beneficial for customers that do not use online banking. The cost of ownership could be reduced as well by using industry standard protocols. No more custom glue. Banks can now create agile back-end infrastructures that can handle tedious Mergers and Acquisitions for example. Having a consistent message layer to handle those ATM course grained services.
Also many of the ATMs now run Windows XP instead of OS/2. So from a technology perspective it can be accomplished. When we look at the concerns for going to Web Services the common response is that the current bandwidth is minimal and this could move that up a bit. The short answer is yes it will, but not by much. We are still talking about text along the wire (XML). With the text is a more structure and a variety of web services behaviors to choose from. It can be as chunking as you want it. Banks want more technology at the ATMs to support rich user interfaces with functionality such as: check imaging / processing and support for portal type functionality to name just a few.
Example architecture from ATM2Mobile
Most of the current terminal handling protocols today are based on antiquated ISO8583 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?
A potential route that would be both scalable and standards-based would be to 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.
Comments