1. Is an awesome idea. Will it work for the tail-end of the log where most maliciousness will occur? The scenario I see is the hacker grabbing the log, and appending transactions to its copy of the log. When you go to contest those transactions, the bank will have a longer log than what your client has. Don't get me wrong there's a lot of use-cases for this: You received a confirmation that a transaction was cancelled but the bank said it didn't happen: In this case you have proof through the signed log that in fact it did happen.
I would expect the local device audit log to store the server's signed acknowledgement too. With 2-party asymmetric signing this should be pretty much airtight.
A rollback attack is always possible: the bad guy backs up his/her device, does a transaction, and restores the device. (A replay protected memory block + secure enclave can make this hard, but never impossible, to do.) This means that you can't make an ironclad assertion that the very last transaction the bank sees was fraudulent, because you can't be trusted to make such an assertion.
But you're still protected against transactions alleged to have occurred before your last real transaction or, equivalently, you're guaranteed to (in theory) notice the fraud the next time you try to do a genuine transaction.
