Editor’s note: ATM Network technicians are so experienced that they routinely uncover and solve problems that the manufacturers themselves missed. This is the story of one such incident.
A few years back, a major ATM manufacturer introduced a machine that offered lots of great features — big screen, modern operating system, reliable mechanisms and lots of expandibility. But its software lagged behind, making the machines run sluggishly.
So with great fanfare, the company released a software upgrade that turned the laggard into a blazing-fast wonder. Customers clamored for them, and ATM Network began installing them by the truckload.
But we quickly encountered a problem. Cash withdrawals worked fine, but every time a customer performed a balance inquiry, the machine would shut itself down for 15-18 seconds, disrupting transactions.
Our troubleshooting team got involved. After some testing, they discovered that during those 15-18 seconds the ATM was resetting itself by downloading fresh surcharge information and encryption keys from our transaction processing server. That was a normal function, but one that rarely occurred — it was only necessary when there was a discrepancy between the ATM’s settings and the server settings. In this case, however, the settings weren’t changing on either end, so there was no reason for the resets.
The manufacturer didn’t know what the problem was. So our team began asking questions. Were there programming errors in the software code? Had the software upgrade made any changes to how settings were stored? Were there new settings that the transaction server wasn’t reading correctly? The answers came back: no, no, no.
The team finally decided to focus on the odd fact that the problem only cropped up during balance inquiries. From the ATM’s perspective, the main difference between a balance inquiry and a cash withdrawal is the surcharge: balance inquiries are free, withdrawals generally are not. Maybe there was a problem with how the machine decided which transactions had a surcharge and which ones didn’t.
Programmers use something called a “flag” to determine status settings. A transaction that has a surcharge would have its surcharge flag set to “on”, meaning a surcharge is assessed. A balance inquiry has its surcharge flag set to “off”, meaning it’s free.
But as the team dug through the system, they discovered that this machine did things a little differently: the surcharge flag was always set to “true”; all it did for free transactions was set the surcharge amount to $0.
That was odd, but seemed harmless. The effect was still the same: withdrawals had a surcharge, balance inquiries didn’t.
The team did some more digging, with engineers from the manufacturer on the phone to help. Together they soon discovered the problem. Besides checking its own settings, the ATM also verified its settings with the transaction server. But the transaction server had only one surcharge amount listed — the surcharge levied for cash withdrawals. This made sense, because if the ATM used the surcharge flag properly, then the only time a surcharge would be triggered was during a cash withdrawal.
But in this case, the ATM was triggering a surcharge on balance inquiries, too. And that $0 surcharge didn’t match the surcharge information on the server. So the ATM assumed its settings needed updating, and took itself out of service while it downloaded new settings from the server.
Thanks to the combined efforts of ATM Network and the manufacturer, the manufacturer wrote and released a software patch fixing the problem.