|
|
|
|
|
by klabb3
855 days ago
|
|
It’s not terribly difficult in case of financial transactions. Just separate into queueing and executing, with an auto-timer, notifications (email, push etc) and an option to cancel directly from the notification channel (without requiring 2FA etc to prevent hijacking issues). This could be applied to other things, like updating an auth factor (change email for instance). Just notify the old email and queue the operation. Doesn’t solve all the issues but gives humans a chance to counter bots and hackers based on speed alone. The main engineering challenge is to estimate impact of an operation, since it depends on other actions. For instance, exfiltrating $1M in $5 increments should not be possible. |
|
The friction is already there.
Every single goddamn time I want to transfer more than a few thousand dollars between any of my accounts, it turns into a complete shitshow of bouncing transactions, hunting down reasons, navigating bureaucracy that doesn't want to be navigated, sometimes to the point of looping in authorities (!), and generally burning many hours of my life to get the financial institutions to do their most basic job.
It's not great. If the purpose is security, we can do better, but I'm not convinced. If the purpose is because financial institutions know that they can prevent customer outflow by shitting up the outgoing transfer mechanism, we should make them do better. If this drop in friction makes security worse, then we should go back and make security better again using a type of friction that isn't such a fucking migrane to deal with.