And if two commands get stored in quick succession, such that the first results in a state that renders the second impossible? Particularly if some of the balance updates in the first command, are contingent on others ( credit line backing checking account updated if deposit balance < 0, for example )?
Financial transactions are pretty much the poster child for atomic, multi update transactions and pessimistic locking.
You can always save the fact that a transaction was started, read the account's state (including the most recent transactions as an ordered list), calculate the validity of the item, and update the success/failure accordingly.
It is not the transaction itself that is hard, it is the network partition. E.g. what happens if two network partition approve transactions, that wouldn't have been accepted if there were no partitions.
I've probably gotten off base here by wanting to perform arbitrary actions against services I may or may not control in the course of satisfying a command, and worrying too much about made up corner cases.
If this DB is the sole record of The Money, and I can move some quantity from X to Y in a transaction, then that's fine by me.
Financial transactions are pretty much the poster child for atomic, multi update transactions and pessimistic locking.