Hacker News Reader

Comment by josephorjoe | Hacker News Reader

That UI is depressingly awful, and not having a confirmation screen with a summary of the transaction about to be initiated is so very very bad that it should get people fired.

Pretty much every modern financial app I've used has one of those confirmations - some better than others but all pretty clearly state "you are going to transfer $XXXX.XX to ACCOUNT_YYYY -- click here to approve transfer".

Even venmo's quick prompt to make sure you really mean to send your pet sitter $125.00 before initiating a transfer would have avoided this problem.

View on HN

The thing is, this is where the difference is between internal and external tools. Your client facing app has to confirm every action because the client isn't expected to have a deep understanding of the process. Bank employees are expected to have that understanding, so I'm not surprised there is no confirmation window. It's like with Linux - certain completely destructive commands have no confirmation before running, because clearly the user knows what they are doing - otherwise why did they type in that command in the first place.

Since firing an employee won't bring the $500,000,000 back, I'm thinking the linux philosophy is probably not the best one to use here.

The linux approach is "what you are doing is not my problem, so go do whatever you want".

For a bank, what their employees do is very much their problem.

> Bank employees are expected to have that understanding, so I'm not surprised there is no confirmation window. It's like with Linux - certain completely destructive commands have no confirmation before running, because clearly the user knows what they are doing

Well, no, it's not like that at all. There IS a confirmation window; it's just not embedded in the software. Three different people -- the flunky, his boss, and his boss's boss -- were all required to confirm the validity of the transaction before making it.

And there was a confirmation window in the software, it just didn't distinguish between some and all of the funds being wired out of the bank.

> Raj then proceeded with the final steps to approve the transfers, which prompted a warning on his computer screen — referred to as a “stop sign” — stating: “Account used is Wire Account and Funds will be sent out of the bank. Do you want to continue?” But “[t]he ‘stop sign’ did not indicate the amount that would be ‘sent out of the bank,’ or whether it constituted an amount equal to the intended interest payment, an amount equal to the outstanding principal on the loan, or a total of both.”

(from the judge's opinion, via Matt Levine and Bloomberg)

Also confirmation is undesirable UX.

In this case it may be the best option you have, but the UX you should be aiming for is always undo.

Humans are always sure this is what they wanted to do right up until they understand the consequences. Then they experience regret. If possible design your software so that regret has a natural response in the interface in the form of an "Undo" option.

A confirmation step doesn't trigger that "understand the consequences" outcome, and so users will mostly be annoyed by the confirmation, and pick "Confirm" even when in fact they'll immediately regret that once they do it. They may even ask you to add another "Confirm" step. You want "Undo".

Notice the law here reflects this preference for Undo. If Citibank wired $500M to me the law says they get to Undo that, because they didn't owe me $500M and so that's just a mistake. They can't undo this because it looks exactly like a legitimate payment to a creditor, and if you could always undo those it opens a real Pandora's box. Normally you can "undo" paying a willing creditor because they'll just lend you the money again. But of course not everybody is a willing creditor, as in this case. Boo hoo for Citibank.

Right, but the desire to undo is incompatible with the desire to have fast transfers. Yet another solution to this problem would be to have transfers take 24 hours during which they can be "un" sent by the sender, but I imagine banks will have a very strong preference towards instant or very very fast transfers.

Not saying the Linux analogy isn't good, but this is more like if entering the flags for `tar` in the wrong order could send you and your immediate family into irreversible ruin forever.

It simply should not be possible, this is about literal tons of money, they shouldn't rely on something this banal.

Simple safeguards can be put in place to prevent this. They don't even need to be very fancy:

Fairly sure a simple trained-human-readable description of what was about to happen (think: this money will go to this acct, this money here and this other money over there) would have saved this people a whole lot of grief.

I saw a great Linux quote recently. I'm paraphrasing, but it goes like:

"Linux gives you enough rope to shoot yourself in the foot. If you didn't think you could shoot yourself with a rope, you should read the man page first."

That said, as Linux has gotten more popular, it's put more safeguards in. For instance, you can no longer "rm -rf / file.txt".

I know someone that works for a (smaller) bank regularly processing loans in the mid six figure range. When I think about all the steps she has to go through around verification on each loan, It's just crazy to me how they're able to accidentally send an amount over 1000x times what she has to deal with.

Reply on news.ycombinator.com