Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,125 | Comments: 45,488

filter by tags archive

Your ATM doesn’t use transactions

time to read 2 min | 363 words

I just got a series of SMSes from my back, saying that someone just made several withdrawals from my account. As I am currently sitting and watching TV, I was a bit concerned.

It appears that my wife withdrew some money, but there was an issue with one ATM machine, so she used another one.

The problem, I got 3 SMS messages, saying that the follow activities happened on my account:

  • ATM withdrawal for 2,000 NIS
  • ATM withdrawal for 2,000 NIS
  • ATM withdrawal for 2,900 NIS

Checking with my wife, she had actually withdrawn only 2,900.

I was a bit concerned, so I logged into the bank and got this:


In English, this is:

Date Description Auth Code Debit Credit
10 Apr ATM withdrawal 00003581 2,000  
10 Apr ATM withdrawal 00003581   2,000
10 Apr ATM withdrawal 00003581 2,900  

This is actually interesting, because the way my wife described it, she wen to the ATM, punch the right codes, and went through the motions of everything. Then, just before it was about to give her the money, it failed.

What is really interesting? From my point of view, is that I can actually see this in my bank account. We didn’t have a transaction rollback because of failure to dispense the money. That isn’t how ATM works. We actually had a compensating action (that occurred as separate transaction) to show that the ATM refunded the money it wasn’t able to give.

So next time someone tries to quote you “banks use transactions”, you can tell them that the bank definition of what a transaction is would make any decent DTC cry with shame.


Gian Maria

This is quite common in Banking system, since they handle money, the concept of rollback is really dangerous, it is always better have a compensating action, because it retain more information. Each movement should be recorded, and if a movement should be cancelled for some reason (the ATM machine broke and cannot give you money), you can only compensate.


What if the compensating action transaction failed and the not withdrawn debit was not credited back to your account? When my ATM could not give me the withdrawn money, because it did not have a fitting set of bills, it always told me so without (visibly) performing a debit on my account.

Ayende Rahien

Hangy, That is when you have local logging and error correction happening

Jone Polvora

I guess all banks have a concept of "transaction of transactions", the rollback is a series of transactions of compensation actions


Some ATM/banks with slow internet connections for small amounts of money don't even check if You have the money on Your account at this current time (there is a significant delay in updating total amount).


Compensationg actions is transactions for occasionally connected systems like ATMs.

Koen Verheyen

I hope your wifes' pin code is not 3581...


Of course, the action and the compensating action are both written inside of a transaction. There are two transactions here, not one.

This decision surely wasn't purely technical. When it comes to distributed state (like in ATM machines) technical decisions can have business implications.


That is very interesting. I'm not sure how I feel about that. On one hand you would except such an important function to use transactions but on the other it is nice to see where the failure occurred and that the funds were credited back. At least if the proper trail is there it should be simple to resolve any discrepancies.

George Mauer

ATMs have been one of Udi Dahan's example's of SOA for years, I wouldn't even be surprised if he or one of his (or Greg Young's) eventual consistency proteges had designed the system.

The back-of-the-envelope idea is that for many systems it is more important to get immediate feedback and retain ALL history of ALL user interactions than for the entire distributed system to be constantly consistent. When designing a cqrs messaging system you consider the failure scenarios in a bounded context and treat them explicitly. Yes it is possible that the recovery action has an error as well, you can plan for that, and make it a business person's decision how far down that rabbit hole you want to go. In the case where 3 orthogonal, non-dependent operations fail in a row, the bank might decide it'll take its chances with an angry customer.

The thing is that even DTC is subject to CAP theorem, and cqrs (which again, is applied only within a bounded context, not necessarily system wide) forces you to explicitly deal with those limitations.


If I'm not mistaken, ATMs have a paper trail as a form of low-tech audit log that can be ultimately matched to the records. I don't think using correction fluid is an option :-)

Phillip Haydon

You and your wife are lucky!

Last year I went to Malaysia and my friend whom I was traveling with, withdrew about $500 AUD from the ATM... No money came out...

The money was taken from the bank account in Australia, but the bank in KL had absolutely no record of the transaction at all and tried to dispute that the ATM transaction did not take place.

It took about 3 weeks to get the money back...

The scenario you described, I wish MORE banks implemented because clearly it works!

Kevin LaBranche

I agree that this is interesting in that a record was made even though it failed. I believe that was your point in the first place. :-)

Since it did make it into the accounting; not deleting the transaction (debit/credit) is normal procedure for accounting situations. It's known as T Accounts. http://www.cliffsnotes.com/study_guide/T-Accounts.topicArticleId-21081,articleId-21009.html

One of my first systems I wrote required that every debit transaction type had an opposite credit transaction type.

Kyle Szklenski

Ayende, we all know you were quite upset with all the women out there and instead set out to write your own wife as a computer A.I. When can we expect a RhinoWife Profiler?


Compensating transactions are also superior if there is any degree of async/parallel 'business process' (particularly if there is Human Workflow-centric exception handling). They are also good if there are multiple external partner systems involved that you have no control over; it's a looser dependency. There is no silver bullet though; compensation can become arbitrarily complex very quickly as the transaction nesting level increases. At a certain level of complexity, automatic recovery is no longer manageable, so it is common to use HWF-centric exception processes that 'adjudicate' the compensation process.

Arnon Rotem-Gal-Oz

Pat Helland wrote about this a few years back "Accountants don't use erasers" http://blogs.msdn.com/b/pathelland/archive/2007/06/14/accountants-don-t-use-erasers.aspx


Regardless of whether this is a good design decision or not, banks should not be held up as a good example to follow.

The worst code I've ever seen lies in financial systems.

Anonymous Coward

DTC's are expensive ...

In any case there were probably 25 systems in the chain going from ATM to Account where it could have failed. Not all of them can be involved in a coordinated transaction. Both from a practical and technical point of view.


Unfortunately many banking and financial systems still have their underpinnings stuck in the dim and distant past (70's). The APACS protocol used in the UK was devised for use with modems. It's been adapted and butchered for different types of transmission and bank transaction types. It has to be one of the most antiquated protocols there has ever been yet their is no desire to change it for something more flexible and expressive.

More worryingly many of the banking protocols have no inbuilt form of security or message authentication. They are wholly reliant upon the use of private or closed networks.

Interestingly you have the same auth code, often banking terminals (ATMs, PEDs etc) will reuse the same terminal message number for a subsequent transaction to indicate that the transaction reverses the previous one.

As Flukus said, banking systems are poor examples of how something should be done.


I think the problem is that the word transaction is a loaded one for database developers. ATM transactions involve physical interactions which can't be rolled back (giving money to a person.) Rolling back a database transaction during a failure doesn't rollback the entire transaction (the money doesn't dissapear from a theif's pocket.)

Additionally, you're making the assumption that a transaction isn't occurring at the database level by what you see on your bank ledger. It's entirely possible that the ledger is constructed from reports produced by the ATM, and the appearance of this as a credit/debit pair is due to constraints of your bank ledger, not the ATM's transaction system. It's also possible that the ledger appears as it does because analysis has shown that (most) customers react better to seeing a credit/debit pair on their ledger than another means.

In either case, it's dangerous to assume that something is wrong, until you have actual evidence.I don't know how many times wild assumptions have come back to bite me as a professional...

Hector Cruz

Maybe your wife just got robbed. Years ago in Mexico, there was this device that bad guys put over the ATM's that look like the original thing but puts your money in a secret compartment when asked for it. Then the bad guys came and remove the "mask" and took your money. The bank could swear that everything went just fine but ...


There's a lot of talk here about transactions and what not, but it's really a lot simpler than that. From the banks perspective, they don't want to give out money unless it's been recorded. Consider what might happen if you went through the process, the machine belched out it's cash, and before it could be recorded, the power went out or something broke, or the ATM blew up or whatever.. Suddenly, you've disbursed cash, but have no record of it.

So from the banks perspective, it needs to record the transaction, and THEN give out the money. If the disburser mechanism is broken, then it won't know until it tries to disburse the cash.

It's simply far more important that a record exists before any cash leaves the machine. And since, once a transaction is recorded, it cannot be unrecorded, a correction must be made. It has nothing whatsoever to do with transactions. It's all about protecting the cash.

Comment preview

Comments have been closed on this topic.


  1. The design of RavenDB 4.0: Physically segregating collections - 8 hours from now
  2. RavenDB 3.5 Whirlwind tour: I need to be free to explore my data - about one day from now
  3. RavenDB 3.5 whirl wind tour: I'll have the 3+1 goodies to go, please - 4 days from now
  4. The design of RavenDB 4.0: Voron has a one track mind - 5 days from now
  5. RavenDB 3.5 whirl wind tour: Digging deep into the internals - 6 days from now

And 12 more posts are pending...

There are posts all the way to May 30, 2016


  1. The design of RavenDB 4.0 (14):
    03 May 2016 - Making Lucene reliable
  2. RavenDB 3.5 whirl wind tour (14):
    04 May 2016 - I’ll find who is taking my I/O bandwidth and they SHALL pay
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats