News

Is there still a place for static states and screens?

We 'techies' have to admit that an ATM with the power of a browser user interface, managed by a dynamic script, activated by biometrics ... is 'Freedom' and a thrill only Tim Taylor can appreciate.

November 5, 2003

The writer is with Paragon Data Services LLC.

We have been hearing about web-enabled ATMs for more than six years. Where are they? What are they doing? Why do we need them? Most importantly, who needs them?

"Web-enabled" was a catchphrase we attached to the new ATM software architecture during the dot.com era. It captured the imagination with an image of unlimited transactional access, high-connectivity, browser user interface and open development. But it also misled. Many first assumptions were of long lines as consumers surfed at will in front of raging cash-withdrawal customers. "Web-enabled" has now been replaced. The ATM manufacturers' new catch word for their open architecture solution is "FREEDOM." Most still cannot capture the dollars and sense of making the transition, but some have: the big guys and the new guys.

A solid justification for an open architecture strategy in ATM software is a clean slate. The ATM has been used as the delivery vehicle for a number of new types of solutions. Check cashing, payroll distribution, ticketing, money orders; all have been deployed using the open solution. When a new group approaches this activity without an existing infrastructure or bias, they have typically selected the Windows, browser-based, object-oriented programming environment on which to base their new application. The development has been quick and easily adopted. It is also important to point out that all of these functions have been accomplished by others via the tried and true states-and-screens architecture.

You can also justify the numbers when you have the numbers. If you manage thousands of ATMs in your network, you likely have thousands of other devices in your enterprise as well. Commonality is cost justification. The top-10 financials in the U.S. have open-architecture ATMs either in production by the thousands or in the test lab ready for rollout. The investment is in the future if not realized in the present: enterprise integration, common development, enterprise management, rapid deployment of changes, multi-vendor single application, ubiquitous operating system, common-user interface. These add up to justification when your X factor is over a thousand. If it isn't, then it can be a stretch.

To minimize the stretch, the one thing we absolutely know about the future is change. We have demonstrated that those changes can be realized more quickly with the new open tools. The next change on the horizon is Check 21, a change to the check processing law. For those wanting to leverage this new law at the ATM, there is tremendous value in imaging checks as they are fed directly into the depository without envelopes and transmitting those checks electronically through the enterprise back to the issuing bank. This is another factor in the business case justification.

Those ATM owners below the top 30 still consider their ATM channels a critical piece of their financial deployment strategy. Their customers require 24-7 access to their cash. They need cost-effective means of adding voice and Triple DES to their units. They need a solution when OS/2 goes away. They need assistance in the management and direction of their ATM channel.

The gap between the software options and deployments at the high end and those at the low end has never been wider. The point here is that the value of what is low-end and high-end is relative. If high-end is "Freedom," the question is asked by many "freedom from what?" If my strategy as an ATM owner is to maintain the same high-availability of cash access for my customer base and to maintain compliance while managing costs, then I do not need to be "freed" from my existing software configuration. The ATM guys are still building OS/2 solutions with Triple DES and voice options. If someone buys and installs this over the next 12 months, the ATM guys will support it after IBM goes away (which is now December 2006). Each entity is still getting exactly what they need.

It is incumbent upon those of us in the industry to understand all of the technologies and counsel our clients on what makes most sense for them based on their strategies and goals. Each solution, high-end and low-end, has tremendous value for the appropriate environment. We have to have solutions and resources able to build HTML scripts or manage states and screens, understand IFX or ISO8583, configure IP addressing or an asynch dial modem. It will become less and less likely that our clients possess the knowledge base to balance all of this, nor should they. They need to partner with those they trust, and we need to deliver the most appropriate solution.

We "techies" have to admit that an ATM with the power of a browser user interface, managed by a dynamic script, activated by biometrics, riding a high-speed pipe, pulling content from distributed servers, able to access a myriad of CEN XFS hardware devices, grabbing authorizations from a universe of IFX services all managed by a single SNMP monitor is "Freedom" and a thrill only Tim Taylor can appreciate. We just have to remember that to the rest of the world a static, states-and-screens ATM can be a thing of beauty as well.