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.