
Your ATM does not use transactions - sabya
http://ayende.com/blog/155969/your-atm-doesnrsquo-t-use-transactions
======
jeremyjh
I support ATM client software for a large Bank. I want to make just a couple
of points regarding this article and comments.

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.

~~~
lurkinggrue
COBOL...

    
    
      *Shudders*

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

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.

~~~
jacques_chester
> _Actually they don't need to use transactions at all in accounting. All they
> need is a debit history and a credit history._

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.

~~~
babebridou
Isn't accrual accounting the use of an account to log transactions at the time
of sale rather than at the time of payment? If so the same technicalities
apply, you can log your credits and debits in different accounts, no need for
ACID transactions here, unless my experience in this area is flawed.

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

~~~
jacques_chester
> _you can log your credits and debits in different accounts, no need for ACID
> transactions here,_

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.

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

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.

~~~
Zenst
Double entry accounting <http://en.wikipedia.org/wiki/Double-
entry_bookkeeping_system>

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.

~~~
chiph
Any modern bank will process deposits before withdrawal, or process them in
order of entry. With the introduction of ATMs, the order of operations during
the day by the customer could have been:

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

At no time were they overdrawn. Evil Bank® would have done as you suggested,
with the reconciliation at the end of the day being the old paper-based
approach of:

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

~~~
FireBeyond
KeyBank assessed me $360 of overdraft fees for a single day for a similar
thing, where a check/cash was deposited (and it wasn't related to check
deposit policy, that much was multiply verified in the arguments with various
managers), and I went shopping with my partner for Christmas afterwards.

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

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

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...](http://blogs.msdn.com/b/pathelland/archive/2007/06/14/accountants-
don-t-use-erasers.aspx)

~~~
gadders
Most modern ATMs are actually PCs running Windows. Not sure if that qualifies
as "slow and clunky".

~~~
arethuza
I was thinking about the actual mechanism that counts and ejects the notes -
which is pretty slow by computing standards!

~~~
gadders
I heard an urban myth the other day that the cash-counting noises are fake and
are computer generated to cover the time it takes the ATM to communicate with
the mainframe.

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

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

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.

------
gnu8
Financial transactions are different from database transactions despite using
the same word; hackers shocked at the discrepancy. Film at 11.

~~~
Firehed
Not really, and as someone who works on just such a system, please let me
assure you that you simply cannot design a reasonable system without DB
transactions for at least certain processes.

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.

~~~
jacques_chester
I think his point is that the nomenclature is overloaded.

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

------
dhx
Eric Brewer[1] describes why ATMs are not designed for consistency[2] at [3]
(scroll down to the last two sub-headings).

[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...](http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-
have-changed)

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

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.

------
devmach
I always thought they use transactions but in a different way :

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 ?

~~~
sp4rki
That is exactly what I've always though happens. I'd argue that, with ATMs,
since you're dealing with software that after a transaction has passed
commands hardware to mechanically dispense pieces of paper that there are two
different processes going on.

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.

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

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

~~~
babebridou
In practice you can work around transactions in double-entry registers with
UUIDs, and then fixing the inconsistent edge cases at reporting time.

~~~
jacques_chester
In practice doing this for a banking account system will land you in jail.

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

~~~
babebridou
IFRS and GAAP require real-time consistency? Because that's what I meant with
edge cases, entries that are split between two accounting periods. You deal
with them in eventually consistent systems just as you would in an ACID
system: wait and interpret it when the data is complete.

~~~
jacques_chester
Transactions that span two periods basically don't exist in accounting. It's
assigned to either side, or you do two different transactions. One way or
another, the goal is to ensure that you don't have uncertainty.

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

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

\- 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?

~~~
smackfu
The cash dispenser part is probably just a black box with a simple interface
that accepts a message to "dispense some amount of cash" and that can respond
"request failed" or "request succeeded". It may even have no concept of
inventory and just knows that it tried to dispense X bills and it only got X-1
of them.

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.

~~~
edoloughlin
What drives me nuts is that it knows the smallest denomination at the end of
the transaction but out doesn't remember this for the next transaction.

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

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

~~~
4ad
This is not how transaction work, that's exactly the type of failure they
protect against. In fact, the behavior you describe is possible now, without
transactions (it even happened to me a few times).

------
Confusion
This may be an overinterpretation of the bank statements. They are _a
representation_ of what happened, but do not necessarily accurately reflect
the steps that happened.

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.

~~~
sirclueless
If a tree falls in the forest...

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

~~~
Confusion

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

Yes. And the scenario I propose is that your bank statement says you withdrew
an amount and later regained that amount, while in the intermediate time the
actual amount attributed to you by the bank was always the original amount. If
a significant other was withdrawing from the same account at the same time, it
may have been possible to overdraw beyond the usual limit. As long as that
would eventually come to light, due to eventual consistency, that's not a
problem (and undoubtedly something you contractually agreed to take as a
risk).

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.

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

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

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.

------
tytso
Sabre, the airline reservation system, doesn't use transactions either, for
very similar reasons.

------
jpswade
"I just got a series of SMSes from my back"

Not bank?

