I support ATM client software for a large Bank. I want to make just a couple of points regarding this article and comments.<p>First, the article is correct, no distribution transaction coordinator like you would find in a Java application server is going to be involved here. Still, the authorization server maintains a session state and will ensure correct messages are sent to the downstream accounting systems.<p>Keep in mind, there are many downstream systems. There is at least one direct deposit system for standard bank accounts, often there is a linked money market account, brokerage account, and then there are all the gateways for the acquired traffic like Pulse, VISA, etc. The ATM's back-end authorization system will generally send the same sort of messages to these providers and they are responsible for both authorization and transaction recording.<p>What shows up on your statement has nothing at all to do with the ATM or the authorization system. It will depend on the deposit accounting system. These systems are probably pretty old; likely COBOL apps using VSAM (flat files) or IMS databases. They are mostly batch-mode systems which means reconciliation happens once a day and everything intra-day is posted to a memo file. These days those memo-file entries can be queried and a web app like online banking can show you entries that have memo-posted. But the next day, what you may see may look a little bit different. The message the authorization system sent would be clear that for example no deposit actually succeeded, that there should be a reversal. How exactly that is recorded and what you see in your statement is another matter and there certainly are advantages to simply posting it as an offsetting credit.
Actually they don't need to use transactions at all in accounting. All they need is a debit history and a credit history. Using transactions locally could be done but the resulting software would be far too complex for ATM hardware. Using transactions globally would be a huge performance sink considering their frequency over the world.<p>The only time I can think of that would involve a transaction (with a lock) would be when naming a credit movement or a debit movement for future reference (compensation for example), and even that can be "solved" using UUIDs with carefully chosen machine identifiers.<p>The result is a very asynchroneous, very distributed and eventually "consistent-enough" logging system. Just pick the right time to do your reporting (end of the month, end of the year etc), and accept that some figures won't reflect exactly the reality of the balance, since some compensations are done immediately (automatically) while others are performed, manually, days or week later.<p>The whole system makes it very hard to catch transactional events with certitude, that's the main drawback, since nothing proves that a given transaction was "real" and won't be compensated later on.
ATMs have an offline operation mode (CAP blah blah) that is quite permissive with what you can withdraw. This is for the obvious reason that the mainframe is not always reachable and available; but to halt the operation of all cash machines is generally considered less than ideal.<p>I don't have a firm line on the etymology, but it seems to me that what we computer science types call a transaction is so called because of the accounting concept of a transaction.<p>In book entry you must always enter two items: a credit and a debit. Always. Before you make the transaction, the books are supposed to be consistent. And after, they are consistent.<p>One thing accountants do differently is that there are no deletes. You may only update. There are specialised transactions for correcting errors. Again: even if an error has been made, the erroneous state is still consistent before and after an erroneous transaction. And it is consistent before and after the correcting transaction.
I wouldn't have expected something as slow and clunky as an ATM to actually enlist in a distributed transaction - so it hardly surprises me that they might not.<p>There is a moderarely interesting article linked to in one of the comments that sort of sums my expectations up "Accountants Don't Use Erasers":<p><a href="http://blogs.msdn.com/b/pathelland/archive/2007/06/14/accountants-don-t-use-erasers.aspx" rel="nofollow">http://blogs.msdn.com/b/pathelland/archive/2007/06/14/accoun...</a>
It's called roll-forward compensation transaction. It's still a transaction because at the end your account is still consistent, wrt to its balance.<p>The bank logs all the operations including the mistake and the compensation (debit) to make your account whole again. The bank is showing you the transaction log which is usually hidden in a database transaction you normally encounter in RDBMS.
Eric Brewer[1] describes why ATMs are not designed for consistency[2] at [3] (scroll down to the last two sub-headings).<p>[1] <a href="https://en.wikipedia.org/wiki/Eric_Brewer_%28scientist%29" rel="nofollow">https://en.wikipedia.org/wiki/Eric_Brewer_%28scientist%29</a><p>[2] <a href="https://en.wikipedia.org/wiki/CAP_theorem" rel="nofollow">https://en.wikipedia.org/wiki/CAP_theorem</a><p>[3] <a href="http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed" rel="nofollow">http://www.infoq.com/articles/cap-twelve-years-later-how-the...</a>
jeremyjh did a good job explaining this. I work for a company that supports the card issuance side and previous to that I worked for one of the largest drivers of ATM's for small and regional banks.<p>This has nothing to do with transactions in the sense of database transactions or a transaction manager managed by an app server, these may still be used behind the scenes.<p>jeremyjh did a good job explaining this. I work for a company that supports the card issuance side and previous to that I worked for one of the largest drivers of ATM's for small and regional banks.<p>This has nothing to do with transactions in the sense of database transactions or a transaction manager managed by an app server, these may still be used behind the scenes.<p>What happens here is the ATM sent a withdrawal request over the network, that was recorded by the issuing bank - a memo to that account - the bank recorded a debit. Subsequently, the ATM/network/something failed and a second 'reversing' request was sent over the network to the issuing bank, this reversal credit rollsback the initial credit - this may or may not get memo posted to the bank account in real time because reversal transactions can be processed at a lower priority.<p>During the end of day settlement process, the ATM network 'settles' up with each Bank, during this time the debit/credit markup transactions are dropped and replaced by the REAL activity posted by the ATM network (STAR/Pulse/Cirrus/etc).<p>ATM systems are a lot more complicated than a simple database transaction, and even I left out several of the steps and possible events that could occur during the process.<p>During the end of day settlement process, the ATM network 'settles' up with each Bank, during this time the debit/credit markup transactions are dropped and replaced by the REAL activity posted by the ATM network (STAR/Pulse/Cirrus/etc).<p>ATM systems are a lot more complicated than a simple database transaction, and even I left out several of the steps and possible events that could occur during the process.
I always thought they use transactions but in a different way :<p>Atm debits an account first using a transaction and after that if something wrong happens atm credits an account with "second" transaction. If second transaction fails, bank can always check the situation and credit later if it's necessary.<p>Maybe somebody with an experience elaborate how the process works ?
I'm sure banks do use transactions, just not in a distributed system. It's hardly possible to use transactions when multiple entities are involved and you wouldn't want to anyway because you want a record of the failure, and that money actually moved.<p>I suspect they do use transactions when, for instance, inserting two rows in a double-entry register.
There seems to be a few people who work with ATM software here at the moment, so perhaps one of you could answer a usability question that bugs me about ATMs:<p>- On entering my PIN and selecting the option to withdraw cash, I'm presented with a number of choices (e.g., €20, €50, €90, €200 etc.).<p>- I select €90 and wait the ~10-20 seconds for the ATM do do whatever it needs to do.<p>- I'm presented with a message telling me that the machine can only dispense multiples of €50, obviously because it's run out of smaller denominations.<p>- I'm returned to the 'amount-selection' screen and presented with the same set of choices, including the invalid ones.<p>I've now wasted almost a minute. Why doesn't the ATM just limit the list to what it's capable of dispensing? Is there some weird security consideration I'm missing?
I think this kind of makes sense. Think about it the other way, if it were to use transactions the flow would be like this:<p>[Assuming you've entered the PIN, and you've pressed the 2000 button to withdraw cash]<p>a) Check the cash dispenser has enough funds to withdraw 2000<p>b) Contact bank, reserve 2000<p>c) Tell cash dispenser to dispense 2000<p>d) Contact bank, commit 2000<p>Now for newer ATMs I'm assuming it is a bit different, but older ATMs used dial up modems which I'm guessing were pretty slow and unreliable. Ping times in the hundreds of milliseconds wouldn't have been uncommon. During the time taken to dispense it, you could even yank out the telephone cable. My point is, if the ATM failed to send the commit message, the bank would have just given out 2000 to someone for free.
This may be an overinterpretation of the bank statements. They are <i>a representation</i> of what happened, but do not necessarily accurately reflect the steps that happened.<p>For instance, it is entirely possible the 'withdrawal' action was logged before it was actually committed and that it subsequently was never committed, because of a transactional failure. The 'deposit' action was then logged by the rollback code, to create the necessary illusion of restoring balance, while in fact the money never left the account.
Red herring? I imagine the bank is still using transactions when it debits your account and credits some internal ATM-withdrawals account, and again when it reverses the process.
I deal with loyalty programs on a daily basis. While they have much more leniency in terms of fraud and security, you still want to know what happened at every interaction with the main balance.<p>A rollback is dangerous in a loyalty program because when scams happen they become very difficult to trace. I totally agree with the policy of never erasing a monetary debit or credit.