Hacker News new | ask | show | jobs
by raesene4 3782 days ago
I wonder why you got downvoted for this, for me security is a key concern for the challenger banks.

What Mondo is (from my reading) trying to do is very cool but quite ambitious. A new bank in 2016 will be a serious target for quite sophisticated attackers so they're going to have to do app/inf/ops security very well do avoid damage.

On the flip-side they have the once in a lifetime golden opportunity of a green-field deployment to actually get security baked into their systems before they're live without a load of legacy cruft holding them back.

1 comments

I would really like to get an account but don't live in the UK unfortunately.

They talk about the card revocation/freeze in the app in the talk posted earlier, which is a really nice idea (next to the metadata collection). The reason most 'normal' banks have limitations on their apps is that either they will not (or can not) guarantee the safety of their apps or want to place the responsibility at the users end. This means the limits in place (usually ~750/1000 euros max per day/week on mobile platforms) are there to make sure they won't loose too much money if people start saying "I didn't make that transfer". Banks pay out anyway (at least here in the Netherlands) because the customer dissatisfaction is of greater importance than actual tracing the problem of either a hack, an abusive spouse or simply mistyping the IBAN number. Since they collect a huge amount of metadata, this problem gets easier but won't be eliminated and can be managed by good app security and user informing the user. This limitation is the same for card revocation (not freezing, that has other issues; namely concurrency).

I do hope they get a group of 'non HN people' to test it out, as they are more likely to get into the 'I didn't make that transfer' problem.

The problem with freezing cards is that transfers are not direct: freezing the card on the banks end might work, but some ATMs or other systems might have a sufficient delay to allow (some) abuse while the card was 'frozen' by the user. The question will be who will pay for the delay.

I definitely will support these ideas as they stir up a broken market, but please make sure you have you proof-of-possession and concurrency issues well sorted out.

> The problem with freezing cards is that transfers are not direct: freezing the card on the banks end might work, but some ATMs or other systems might have a sufficient delay to allow (some) abuse while the card was 'frozen' by the user. The question will be who will pay for the delay.

This is part of why their cards are online-only, every* transaction has to be verified with them before it can complete at the reader - so transactions are slower, but there is no grace period after the freeze.

* as I understand it, certain merchants are white-listed on-card for offline transactions - namely TfL.

Yep the customer fraud guarantee is a thing in the UK as well (at the moment), and to an extent that minimizes the loss where it's one customer's app. that gets compromised.

Where I was thinking that a lot of their security challenges will lie is things like internal money processing systems. An attacker with access to a bank's internal systems could make a right mess of things...