I'd also considered that Java would be a more robust platform to build from. Its not quite as pure as javascript where everyone can see the code. But at least if it is open source, a determined user could check the bytecode check sum at any time and this should be a strong deterrent to fraudsters.
The problem with Java is the split between Oracle and Google, on top of that, one of the most popular device people use doesn't do Java, or Flash
And we do want something that works conveniently for everybody.
Verifying checksums doesn't help when there are likely to be regular updates to the Java client to patch bugs or improve usability/security.
Even a tech savvy person can't tell if it's a legit change or not compared to the number of web devs who can read Javascript easily. For this reason, the Javascript should not even be minified.
Agreed, javascript is the way to go. Its easy to read, and its on most devices including the important ones for web access (the phone). Obviously its Turing Complete anyway, so it can be done. It would actually be possible to host the javascript on a separate server than the database as well. Downloading compressed js code is more trustworthy from an unrelated party that doesn't have access to the data. And the js would often be cached as well, so some significant size is acceptable. Again, this is all transparent to the non-technical users, and merely the fact that a motivated technical user could uncover fraud is a deterrent.
I'm not as concerned about two factor authentication (which could under some schemes require OS access outside the browser). Ideally you're only keeping a small amount of funds per account, but the design of the service should reduce the attack surface from an owner or hacker trying to steal the funds from _all_ accounts.