Diebold demos cloud-based ATM Diebold has taken the wraps off a prototype for a bank ATM that uses virtualisation technology. Relying on remote servers instead of in-built computing resources reduces complexity while offering greater reliability and security. Diebold described the prototype as a "game changer" and part of its roadmap to make greater use of …
... that added complexity and dependency on a working network connection actually simplifies and secures things? Inquiring commentards demand to know.
That's foregoing dark mumblings on how "delivering elections" to republicans and a whole raft of interesting inconsistencies and other problems large and small with their electioneering machinery reflects on their trustworthyness with money.
ATMs _already_ require a working network connection (and they always have). You don't think they cough out cash without authorization from the bank each time do you? The new scheme might require more bandwidth (eliminating the possibility of using old-school modems on a dial-up or leased line), but it doesn't introduce a new requirement for a network connection.
Heck no. Special cheques, fixed-amount tokens, batch processing with nightly data transfers have all been used at one time or another, if there aren't any in use still. But of course, the current mindset assumes excellent permanent connectivity, whether it is a reasonable assumption or not.
It isn't just more bandwidth, it's also more cpu power elsewhere. Plenty transaction devices perform dialing-on-demand, and that might become a real problem if all the smarts are moved off elsewhere. Especially if dialin is the only thing available and local calls aren't free, as they aren't in most of the world in fact.
Leaving aside that "the cloud" may or may not imply using the public internet which has implications all of its own. While the move might be a reasonable trade-off, to me the announcement smacks more of buzzword bandwagoneering than anything else.
When ATM's where first introduced to Oz, some banks used to go down frequently, taking all of their ATM's with them.
When they fixed this problem by letting the ATM's continue to run without the central connection, people discovered that they could withdraw cash up to the ATM cash limit at each ATM. Since many marginal people have no idea what their bank balance is, they just try to do withdrawals, and were pleasently surprised when the ATM just gave them whatever they asked for.
I haven't heard much about this recently: I suspect that bank systems are more robust now than they were in the 80's. Certainly some of the worst offenders (like the State Bank of Victoria), have simply collapsed with massive debts and been bought out.
The mechanical features of an ATM (the card reader, keyboard, screen, safe, banknote hoppers, banknote handling kit and the printer will, by and large, remain the same because they have to.
The computing element in an ATM won't change much either. It still has to drive the mechanical bits, handle its end of the comms line to the server and drive the cardreader, keyboard, screen and printer. About all it no longer needs to do is run the finite state machine (FSM) that forms the heart of virtually all ATMs.
There should be little effect on ATM reliability since the servers are generally fault tolerant and have been for almost two decades. The effect of comms line failures and ATM breakdowns should be the same as at present.
AFAICT the only effect of this redesign is to move the FSM from ATM to server. The sole benefit will be that the (fairly infrequent) changes to the sets of screens and actions will be applied to a single local copy of the FSM state table rather than being sent over the lines to every ATM. Against this the volume of data sent between ATM and server, and hence the required bandwidth, will be hugely increased because screen images and keypresses will have to be exchanged for every user action.
I can't see any significant benefit to the ATM operator in this, while Diebold gets to replace whole bank-fulls of ATMs and the server manufacturers may need to upgrade their boxes to support the FSMs.
"This consolidation allows greater control and therefore better security, at least in theory. Far from offering a single point of failure, this approach would also allow faster failure recovery and more rapid software upgrades and services deployment, leading to an overall increase in ATM uptime, according to Diebold...."
When was the last time you saw an ATM that was down? They give pretty much five 9s and this is running off XP.
Yes you could load software onto a VMware image faster, but as the software is trickled down the WAN links and installed slowly over the fleet of ATMs a bank has, it wouldn't make much difference - they're still not going to be upgrading all ATMs at once.
The main problem with ATMs is hardware failure, which they would still be susceptible to.
ATMs are a classic market where you shouldn't be using buzzwords.
Cloud does not apply to ATMs, even if they were running in this configuration it's still no more cloud than any generic VMware server. Virtualised != cloud.
There were a couple times when broken ATMs of different brands popped up with gay abandon, but a single broken ATM usually doesn't make the news; people'll just hop over to another. If it does make the news it's usually large chunks of some ATM network, or as here the unified national-but-commercial (magstrip|chip)+pin transaction network, or an entire bank dropping off that network, or some bank's web-facing banking system having a fit. It tends to stand out if electronic transactions suddenly get stroppy. Sometimes for hours.
Reason why I fetch me monies from the dispenser preferrably a day or two in advance before actually needing to, just to have plenty of time to find a non-broken ATM. They're a bit sparsely seeded around here.
Likewise I'm not overly fond of what I've seen of banking software. Like how solaris implemented a shortcut syscall to check that the seconds-since-the-epoch counter still hasn't yet change since the last time asked to speed up banking software's habit of calling time(3) hundreds of thousands of times per second. You know, they could've just measured how many transactions they can do in a second, batch up one tenth of that amount and tag them by batch with the current timestamp. Especially when the banks running the software like to leave the transactions in limbo for a couple days to steal a little interest on the side. The software is only good enough to quell most complaints of "it doesn't work", but it's by no means all that solid. I've seen better. Heck, I've written better. But then I don't work in banking.
Otherwise I more or less agree with your comment, including the software maintenance bits.
Yep, been a while since I saw a blue-screen on an ATM (and I really did..) but hardware failures seem common.
What seem particularly unreliable at the moment are self-service tills in supermarkets - the one next to me yesterday had a window desktop, a DOS-type window saying "this launches something-or-other", a "terminal" window with "Welcome to ASDA" in it, and a pop-up error message box advising it couldn't communicate with the scanner. Looked terribly bodged-together to me!
"Virtualisation removes the onboard computer from the ATM..."
No, it doesn't. You still need to relay user input, manage the network connection, and relay program output. And since LCD screens aren't made of magic, you'll need a thin-client style computer in there to handle that.
So they've gone from a low-power computer in a box in the bank that talks over the network to other bank computers to perform transactions to a low-power computer in a box in the bank that talks to a *specific* bank computer which then relays the same exact request to the other bank computers.
How is this not just adding a needless layer of potential problems?
Yep, the very same, except Diebold has been in the financial industry a lot longer then the farce they called computerized voting machines.
About the same quality assurance, though...
Personally, I think it's someone trying to complicate something that doesn't *need* complication.
Mines the one with the armored EMP-proof wallet pocket.
This post has been deleted by its author
"Banks have historic large estates of ATMs running XP, which do need upgrading to Windows 7."
Umm, you're really going to have to elaborate on that before I take the rest of your post seriously.
This would be some headless embedded form of XP, to which MS have already committed to supporting out to around 2017. It would also have been subjected to extensive testing of its very limited number of use-cases. If you are concerned about proven reliability, moving to Win7 would be nuts.
If, on the other hand, you are simply concerned with being new and sexy, you should be targetting the Win8 beta. (What could possibly go wrong?) Win7 is, well, sooo last year.
This post has been deleted by its author
I've never understood why ATM manufacturers insist on using mainstream desktop OSs. There are any god's number of embedded OS that would easily perform all the required functions of an ATM (except maybe the more extreme eye-candy advertising that seems to be becoming more prevalent these days), wouldn't be dependent on the whims of MS, have a much smaller footprint, be more secure and have many, many fewer things to go wrong. It's almost as if their industry is entirely populated by engineers that don't really understand the term "embedded system".
why haven't people realized that VM doesn't improve security or reduce admin load? fussing with hardware is so infrequent.
but obviously diebold is worried about NFC and people having secure and easy ways to buy and/or get cash advances. ATM's are today's buggywhip...
Pennies from heaven.
I suppose this "thin client" stuff could always include a $20 bill printer to be "real thin" as well.
I suspect that all this boils down to having a simple 8 bit micro in the thing and a bunch of memory. It would get all the display images from the "network connection" and send back button pushes back to the server. Then the server will send "dispense (print) bank notes" back to the ATM.
Where do I intercept the connection to flood my paw with nice pieces of green paper with distinguished elder statesmen/crown heads/presidents/bridge icons?
"I suppose this "thin client" stuff could always include a $20 bill printer to be "real thin" as well."
Could do, I suppose. A note printed with a barcode containing some sort of digitally signed authorisation would be at least as secure (and transferable) as the e-cash proposals that have floating about for small transactions.
But have you considered the costs of printer consumables?
If the banks are looking at changing ATMs, perhaps they could change what is potentially a massive flaw in the security of our current banking systems?
The current reliance on PINs.
ATMs have been widely used for nearly 30 years now. Surely someone, somewhere, has come up with a more secure authentication system?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
