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.

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.

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.

  *Shudders*

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.

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.

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.

While what you described may happen somewhere, the pattern in banking systems that I've seen is pretty straightforward and simple to reason about: a cash flow produces two ledger entries within a transaction and is committed with no concept of distributed rollback.

If there are problems with some sort of subsequent step (e.g. the actual dispensing of cash in ATM or invalid routing instructions in a cross-border payment), the original cash flow is reversed with a reversal of the original two ledger entries -- which is precisely what Ayende saw on his statement.

If a correction is also required in addition to the reversal (perhaps SOME of money was dispensed before an ATM loses power), the correction will be encapsulated with another pair of ledger entries.

(These various cash flows will then typically be placed on a payment bus for further processing by various other systems that perform recon, liquidity management, etc. Again, there is no distributed transaction, just simple double-entry accounting and straightforward transactional message queues.)

If by "debit history" and "credit history" you're thinking of how your bank transactions are recorded, then you may wish to look into the concept of accrual accounting.

Merely tracking cash in and out doesn't give you a full view of what the business is up to.

> 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.

Well good luck with selling your "eventually consistent" accounting system.

While I would prefer if accounting systems could be improved to record and aggregate uncertainty for those places where values entered are based on what is realistically an estimation rule (eg depreciation, stock valuation rules etc), the fact is that all such rules are stated as part of the reports. Within that framework, you report as correctly as possible to the cent or better.

Otherwise bad things happen. Accountants lose their charters. Executives go to jail. That sort of thing.

Serious business is ... serious business.

> Well good luck with selling your "eventually consistent" accounting system.

There's a reason why "eventually consistent" works in accounting, and that's the cut-off time. You don't require from your data to be consistent at every instant, but rather require that your accounting be guaranteed consistent at cut-off time, because that's the data that you base your reporting on. One way to guarantee that is to use only ACID transactions, but it's only one of many ways, and it has flaws (that might or might not be blocking depending on how distributed your architecture is).

Um, yes. There is. There totally is.

There's a reason ACID is illustrated with examples based on debiting one account and crediting another at what is a logically simultaneous instance (Atomicity).

Because if you do one and not the other, your accounts are now Wrong-with-a-capital-W-for-legal-consequences (Consistency).

We need these to happen in some sort of order, so we pretend only one such entry happens at a time (Isolation).

It would also be jolly nice if we didn't lose the records (Durability) every time the RAM lost its juice.

> You don't require from your data to be consistent at every instant

Again: yes. You do. That's literally the entire purpose of double-entry bookkeeping: to guarantee that the books are always consistent.

Funnily enough, "Enron" was the first name that sprang to mind whilst reading comment.

I meant that one should accept that at any random moment the data might be inconsistent with the reality, but after the cut-off time the data for the previous period is guaranteed to be consistent.

Optimistic Concurrency Control is another way of achieving this where transaction is kept on the client and posted to the server when transaction is complete without locks.

The problem with just keeping a debit/credit history is that a session can die or go corrupt at any moment, potentially leaving an incorrect transaction leg on the server. A system to detect such cases and back them out would be more complex than using transactions in the first place.

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.

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.

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.

Simply put if you make a mistake you don't correct it with tipex but with another entry to adjust the mistake. This means all mistakes are accounted for and balanced back to normality.

Also worth noting that banks love to process debits before they process credits so you could have 100 units of money in yoru account with another 200 going in and 200 going out. You will then see that on your statment that they have the 100 then the -200 and then the +200, so indicating that you are -100 for a period, evil are they not.

I've had this happen to me, and a few years ago I happened to work for a short time with someone who had formerly been the president of a small regional bank. He confirmed that some banks do intentionally do that, and that many of the banking software systems had configuration options to decide what order to process data (debits or credits first) and that banks looking to make more money could just flip that switch and start raking in more fees.

It's really annoying to have people say that it doesn't happen when a) I've had it happen to me and b) I've had it confirmed by a banking executive.

    Opening Balance: 100
    Withdraw 50 --> 50
    Deposit 200 --> 250
    Withdraw 150 --> 100

    Opening Balance: 100
    Subtract sum of Withdrawals: 200 --> -100
    Subtract penalties: 50 --> -150
    Add sum of Deposits: 200 --> 50

I'm no longer a KeyBank customer (in between that and them cancelling my card for a $1 Roku pre-auth charge as 'suspicious' - but not notifying me, calling, etc, just popping a letter in the mail which arrived three days after I discovered for myself it was cancelled), unsurprisingly, as they refused to budge on waiving the fees (except for one - "you get one courtesy fee waiver per calendar year". The mind boggles).

I believe this resulted in class action law suits, and regulations preventing this behavior, but I can't find any news article about it at the moment.

Worth noting that is not the case in countries != America, and is in fact illegal in many countries.

I read about another case in australia where an ATM was issuing $50 notes in place of $20 notes so once word got out a ton of people turned up to withdraw $80 - it came out as 4 x $50s = $200 ... but they were also asked to pay it back to the bank...

http://www.couriermail.com.au/news/commonwealth-bank-atm-dis...

I really don't know what they expected to get from this to be honest: I mean, I'm pretty sure when you open the account you recognise somewhere, somehow, that if you overdraw your account it's your responsibility to pay it back...

Also according to a ISO standard on magnetic cards with used by banks - track 4 as will have stored the last amount taken out. So even if you have say 1000 units of money in your account and take it all out and then try to take it out again, the cashpoint (even in batch mode) will know. Now if you cloned your own card prior to the transaction and then used that clone, you may or may not be able to withdraw that money again - but would also have to use a different ATM is the one you just used will have a record itself.

Bottom line you can defraud banks out of there money, but it involves breaking the law like any other form of imoral gains. Only true way to rob a bank is to be another bank somebody once said, may very well be the thruest and with that sadly the only way legaly.

That's how I prefer to design my schemas as well. Meaning answers are determined during query vs during load. If I see an UPDATE statement, I assume it's a bad design.

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":

http://blogs.msdn.com/b/pathelland/archive/2007/06/14/accoun...

I'd like to read his take on idempotency in logging system, as this has always been among the harder problems to solve when designing IT architectures for me.

Edit: Here are two more papers from the author, Pat Helland.

* Building on Quicksand - more about eventual consistency - http://www-db.cs.wisc.edu/cidr/cidr2009/Paper_133.pdf

* Life beyond Distributed Transactions: an Apostate’s Opinion - http://www.cidrdb.org/cidr2007/papers/cidr07p15.pdf

I spoke to our ATM dev and test team here, and they told me this is not true.

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.

I'm more than happy to go into significant detail here, but I think it will just get lost in the shuffle of hacker news comments (at some point I should do a proper article on this stuff). Long story short, you simply cannot make things reliable without having a balance change and its corresponding state update happen atomically. There's other parts you would be well advised to do within that same transaction (ledger entries being the most notable) but you could get by doing that separately if you really hate yourself.

What accountants call a transaction is similar to, and probably inspired, what computer scientists call a transaction. But they are not strictly isomorphic.

[1] https://en.wikipedia.org/wiki/Eric_Brewer_%28scientist%29

[2] https://en.wikipedia.org/wiki/CAP_theorem

[3] http://www.infoq.com/articles/cap-twelve-years-later-how-the...

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.

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.

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.

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.

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).

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.

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).

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.

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.

Maybe somebody with an experience elaborate how the process works ?

If the transaction passed (the human facing ATM part at least) you effectively withdrew the money, software wise you actually took it. If something happens in the procedure of actually giving you the money the machine informs something the likes of: "hey Mr. Software, something went wrong here, credit that back please". I'd argue that if everything was enclosed into one transaction you could have an edge case in which the "money transaction" passed, the cash was dispensed, something went wrong just after and you get a roll back of everything but the money was still physically withdrawn.

ATMs have cameras, so in the case that the cash was not dispensed, they can manually fix the problem and credit your account in case of a claim (they have the camera footage and the ATM's paper trail). On the other hand if everything was enclosed into one transaction, it might be a bit awkward for a bank to tell you a week later: "Hey man, we made a mistake and we now need to take out 500 dollars out of you account, but be assured we're right about this here..."

Hell people see the bank crediting you something you did not take as good customer service, but I'm pretty sure that people will complain about the bank taking money from them if it's not done at the exact moment where they took the action of taking said money out of their accounts.

I suspect they do use transactions when, for instance, inserting two rows in a double-entry register.

Banks follow the IFRS or GAAP rules and they follow them because to do otherwise is just a bucket full of indictment.

Ever dealt with a company that's "closing the books?"

- 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.).

- I select €90 and wait the ~10-20 seconds for the ATM do do whatever it needs to do.

- 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.

- I'm returned to the 'amount-selection' screen and presented with the same set of choices, including the invalid ones.

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?

Yes, it could have a query function added, and yes the GUI could dynamically respond to that, but it's a bit of an edge case since the assumption is that the ATM is well stocked if it's got mixed bills.

[Assuming you've entered the PIN, and you've pressed the 2000 button to withdraw cash]

a) Check the cash dispenser has enough funds to withdraw 2000

b) Contact bank, reserve 2000

c) Tell cash dispenser to dispense 2000

d) Contact bank, commit 2000

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.

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.

"the money never left the account" is not really the way to think of this. The bank does not move around piles of cash when you withdraw money, or keep some gold set aside in a vault for your use. "The account" is the amount of money that the bank attributes to you when it is drawn upon.

Basically, I think you are mixing up cause and effect. The log of debits and credits is the account. The balance is some derived number that represents all of the cleared transactions in the account. It is useful because it determines policy around your account (how much interest to give, how much to let you withdraw from an ATM), but it's not the fundamental building block of banking.

  "The account" is the amount of money that the bank
  attributes to you when it is drawn upon.

Transactional algorithms usually require logging to be able to recover from failures. A conclusion of the recovery process can be that certain actions did not take place. A bank statement is a rather sparse log that underspecifies what actually happened.

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.

Not bank?