6 ms·

Your ATM does not use transactions

85 points by sabya 14y ago

arethuza 14y ago
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/accountants-don-t-use-erasers.aspx http://blogs.msdn.com/b/pathelland/archive/2007/06/14/accoun...
- babebridou 14y ago
  "Moderately interesting"? This article is a gold mine on the subject! 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 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 http://www.cidrdb.org/cidr2007/papers/cidr07p15.pdf
- gadders 14y ago
  Most modern ATMs are actually PCs running Windows. Not sure if that qualifies as "slow and clunky".
  - arethuza 14y ago
    I was thinking about the actual mechanism that counts and ejects the notes - which is pretty slow by computing standards!
    - gadders 14y ago
      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.
gmac 14y ago
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.
jpswade 14y ago
"I just got a series of SMSes from my back" Not bank?
lucaspiller 14y ago
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 14y ago
  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).
babebridou 14y ago
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 14y ago
  > 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.
  - 14y ago
dhx 14y ago
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 https://en.wikipedia.org/wiki/Eric_Brewer_%28scientist%29 [2] https://en.wikipedia.org/wiki/CAP_theorem https://en.wikipedia.org/wiki/CAP_theorem [3] http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed http://www.infoq.com/articles/cap-twelve-years-later-how-the...
aneth4 14y ago
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 14y ago
  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 14y ago
    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 14y ago
      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 14y ago
        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?"
Confusion 14y ago
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 14y ago
  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 14y ago
    "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.
jacques_chester 14y ago
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 14y ago
  Double entry accounting http://en.wikipedia.org/wiki/Double-entry_bookkeeping_system 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 14y ago
    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
devmach 14y ago
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 14y ago
  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.
jeremyjh 14y ago
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.
- gadders 14y ago
  IMS here.
- lurkinggrue 14y ago
  COBOL... *Shudders*
ww520 14y ago
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 14y ago
Financial transactions are different from database transactions despite using the same word; hackers shocked at the discrepancy. Film at 11.
- Firehed 14y ago
  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 14y ago
    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.
mpr3 14y ago
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.
jknipp 14y ago
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.
edoloughlin 14y ago
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?
- mikeevans 14y ago
  All the ATMs I've used (which are in the US, so maybe that's the difference) only will allow you to select multiples of $20.
- smackfu 14y ago
  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 14y ago
    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.
- greenyoda 14y ago
  My bank's ATMs display messages like "I only have $50 bills available now", so apparently some ATMs are smarter than others.
tytso 14y ago
Sabre, the airline reservation system, doesn't use transactions either, for very similar reasons.

85 points by sabya 14y ago

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

babebridou 14y ago
"Moderately interesting"? This article is a gold mine on the subject! 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 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 http://www.cidrdb.org/cidr2007/papers/cidr07p15.pdf
gadders 14y ago
Most modern ATMs are actually PCs running Windows. Not sure if that qualifies as "slow and clunky".
- arethuza 14y ago
  I was thinking about the actual mechanism that counts and ejects the notes - which is pretty slow by computing standards!
  - gadders 14y ago
    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.

gmac 14y ago

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.

jpswade 14y ago

"I just got a series of SMSes from my back" Not bank?

lucaspiller 14y ago

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 14y ago
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).

babebridou 14y ago

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 14y ago
> 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.
- 14y ago

dhx 14y ago

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 https://en.wikipedia.org/wiki/Eric_Brewer_%28scientist%29 [2] https://en.wikipedia.org/wiki/CAP_theorem https://en.wikipedia.org/wiki/CAP_theorem [3] http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed http://www.infoq.com/articles/cap-twelve-years-later-how-the...

aneth4 14y ago

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 14y ago
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 14y ago
  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 14y ago
    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 14y ago
      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?"

Confusion 14y ago

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 14y ago
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 14y ago
  "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.

jacques_chester 14y ago

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 14y ago
Double entry accounting http://en.wikipedia.org/wiki/Double-entry_bookkeeping_system 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 14y ago
  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

devmach 14y ago

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 14y ago
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.

jeremyjh 14y ago

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.

gadders 14y ago
IMS here.
lurkinggrue 14y ago
COBOL... *Shudders*

ww520 14y ago

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 14y ago

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

Firehed 14y ago
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 14y ago
  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.

mpr3 14y ago

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.

jknipp 14y ago

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.

edoloughlin 14y ago

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?

mikeevans 14y ago
All the ATMs I've used (which are in the US, so maybe that's the difference) only will allow you to select multiples of $20.
smackfu 14y ago
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 14y ago
  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.
greenyoda 14y ago
My bank's ATMs display messages like "I only have $50 bills available now", so apparently some ATMs are smarter than others.

tytso 14y ago

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