I keep hearing people say Banking systems like ATM use Eventual consistency model for data synchronization, but I am wondering if it is true.

Definitely the amount you withdraw might be delayed showing in your banking statement, but I assume they won't let the amount of your banking account inconsistent at any given time, right?

Anyone working in the industry can confirm this?

  • 2
    Don't forget that the banking industry is hundreds of years older than computing. They did all this stuff with quill pens & ink. In those days an active account would probably be inconsistent most of the time. Remember "floating" a check? Commented Apr 23, 2014 at 16:08
  • 1
    You may find this interesting highscalability.com/blog/2013/5/1/…
    – plalx
    Commented Apr 18, 2015 at 21:36

2 Answers 2


You must distinguish technical correctness criteria from real-world systems requirements.

Certainly banks must be able to account for every withdrawal and deposit, and more generally for every in and out on their balance sheets. That's what regulators are for. But no regulator will ever hold a bank to prove that the accounts were completely "consistent" at any given point in time, particularly if it's long in the past. That's why banks can get away with deducting sums from your account while not crediting the recipient until days later, as long as they keep track of where everything has to go eventually.

In their own trades, modern banks are capable of millisecond-accurate accounting, so obviously this is not a technical limitation. The simple truth is that there is an incentive for the bank to execute deductions as early as possible, and credits as late as possible, because that earns them more fees that doing the opposite, and as long as there is no legislation which forbids this, they have no reason to improve. So 'eventual consistency' in banking is not a technical compromise for lack of a better alternative, as with huge NoSQL data stores - it is plain and simple good business for the money handlers.


I feel @killian's answer addressed forward-dated transactions as opposed to data consistency that the OP was asking about. It's good to note that even in instances where the credit is to be availed to the customer a few days later, the initial debit and credit transactions were committed to the db at the same time, only with the flag that avails the money to the customer being set to some day in future.

Back to the OPs question, yes, the ATMs use eventual consistency model but this is typically minimized to seconds. There are different setups depending on the bank:

  • Realtime - in this setup, the ATM platform gets their balances directly from the core banking system and conversely update the balances directly. In such a setup the customer's account balance will always be in sync. Con for this setup is that the communication between the ATM and the CBS has to be robust else there will be many failed transactions.
  • Offline balances - Some banks opt to download balances to the ATM control servers and have the ATM machines check balances from there. Thereafter the balances are uploaded periodically to the core banking system. As you can see, this is clearly potentially bad for the bank since the customer can do a withdrawal at the ATM and rush to a counter and do another withdrawal before the ATM sync is done. This option is used for remote branches but with advancement in communication technology, it's less and less common
  • Hybrid - This approach employs frequent updates to the ATM balances DB from the core banking system. The ATM application then can use the ATM balance DB as the primary when (if) it cannot reach the core banking system in good time. Cards generally have a very short timeout period

So in second and third scenario, it is possible for the statement from the banking system to be a little outdated before the sync from the ATM is done.

Not the answer you're looking for? Browse other questions tagged or ask your own question.