It's not clear how good compliance with this actually is.
It's not clear how good compliance with this actually is.
I believe the technical term for this pattern is Event Sourcing. See also:
http://martinfowler.com/eaaDev/EventSourcing.html
Event Sourcing describes everything of such a system, except for a mechanism to ensure non-tempering. That's where other technologies such as regularily published hash values come into play - which may be printed in newspapers, cryptographically signed by multiple trusted organizations, agreed on through some blockchain technoloy, or a combination of all.
> What we've used for a decade or so.
The linked Fowler article is from 2005, which is also more than a decade old.
> Fowler is [...] unrelated to the basics of this discussion
While Event Sourcing doesn't describe audit logs and storage systems, it does describe how to build a whole working system based solely on that, with real-world experience warnings about pitfalls and so on.
In other words, the compliance level is actually pretty good, but the solutions themselves are weak and not hardened against intent (just normal operating use).
However, recovering internal state is not really a solution to the main problem - you can't reverse any external transactions that were done based on the temporarily wrong state. If ATM or teller handed out cash, you can't simply cancel that. If you (as a bank) sent a payment instruction to another bank or some payment network, you're often not going to get that money back; especially if it was fraud instead of some mistake.
I wonder if it's possible to specifically cancel the serial numbers of the cash that was fraudulently withdrawn. In other words, make it no longer legal tender. Of course, the problem is how the acceptor of the cash knows that it is fraudulent, but perhaps a public list of serial numbers known to be fraudulent would be a start?
But in an automatic way, no, a public list of known fraudulent serial numbers would not be sufficient in the current legal environment; it would be impractical to mandate everyone to check such a list at every transaction for every single banknote.
There's an essential problem: all security systems can be compromised. When a security system seems more safe than the others, more people will use that system, thereby increasing the incentive for adversaries to try to break it (and almost always they will succeed).
The real goal is to make the cost of tampering exceed the payout. The standard mechanisms for increasing the cost are computational power needed (cryptography) and ability to participate in mainstream society (legislation).
You actually decrease it. The payout of tampering is associsted with assets security scheme protects. As for that point, vendors should sell the solutions as reducing but not eliminating risk. Plus encourage monitoring and audits.