Well the problem with that approach is how you do it when the 2 institutions are far apart and have to process a lot of transactions (not that they don't manage

Well the problem with that approach is how you do it when the 2 institutions are far apart and have to process a lot of transactions (not that they don't manage to fuck it up when we're talking 10 transactions per day, but that's fixable in different ways). Also this does not satisfy the government/3rd party audit issue (which is important in court cases: can an independent expert verify the log in a way that nobody can subvert ?). In your proposal they can still sabotage this cooperatively, aside from the (potential) impracticality of doing that. So what you do is this: 1) log message comes in 2) generate (public, private) key pair 3) sign log message using private key 4) sign PREVIOUS public key using private key 5) erase previous private key 6) store log message, public key and both signatures 7) goto 1 (usually some metadata, such as amounts on accounts, gets included on a regular basis. Usually there's only a very small number of actual accounts since these are exchanges between huge banks. There aren't that many huge banks, especially not in a specific exchange, in fact, mostly only 2. Even in large systems, 10000 is the biggest I've seen) No need for connection to other party, and by on a regular basis sending one of these public keys to both parties, the integrity of the entire log is 100% guaranteed. You can also "prove" what the time was by encoding functions that are well known afterwards and widely available, but not known ahead of time (like variations in pulsar frequencies, or sunspot images. This principle is called a "natural oracle" and does not require trust. But if you can post a sunspot image of day X, that proves the message was not made before X). Suppose you hack this system (whether actually hack it, or simply have the root credentials on hard): you cannot change past log messages without tripping the alarm (meaning both participants can verify with 100% certainty that you messed with them). You can only change log messages from that point forward (and at that point, why not just replace shit at step 1 of the process). Note: yes, you can delete the logs entirely (but again, this trips the alarm), and yes, you can stop the log and change future messages.