Velocity Checking: One lesson everyone can learn from Tesco Bank

Like many credit and debit card acquirers, when Tesco Bank’s fraud system detects what it thinks is a fraudulent transaction on a cardholder’s account it sends the customer an SMS saying “please contact the bank”. It’s pretty obvious that it doesn’t have any sort of velocity checking on this function — which is why, on the weekend of 5-6 November, over 20,000 Tesco Bank customers received such a text message. Many reported spending a few hours on hold to the contact centre.

You can be sure that if you send out 20,000 SMS fraud alerts, a large percentage of those people will contact you — and Sunday morning is not when the contact centre is going to be fully staffed!

What went wrong

The fraud system should have not treated each fraudulent notification in isolation, but it should have also created a consolidated view across the entire system. As soon as the consolidated view noticed it had sent out an abnormal number of alerts in a 10-minute period then it should have:

  • Paused sending out alerts to customers
  • Sent an alert to the SOC saying “Help, I’ve seen fraud on 2,000 accounts in 10 minutes which is five times more than normal. I think we’re under attack and can you get more people in the call centre for tomorrow morning?”

Of course – the system could also have been clever enough to notice that all these alerts were caused by the same sort of abnormal transaction (in this case magnetic stripe contactless debit card transactions from outside of the UK) and the system could have also set this transaction type to auto-decline. This would have perhaps had the benefit of stopping the fraud continuing.

Lessons for everyone

It’s not uncommon for developers to think of a problem in isolation: “if X happens then assume this account is being attacked so do Y” but developers should also think of the system-wide view. There must be something in a system to address the question “is it just one account that’s being attacked, or is this part of a systemic attack?” Fixing this can be as simple as writing to a log that another process is monitoring — looking for patterns and abnormal velocities — which can then follow its own business rules to detect and respond to systemic attacks.

We can all learn this one lesson from Tesco Bank: think systemically. If you have a system that sends SMSs to customers asking them to call you, or something that locks accounts after ‘n’ bad attempts, how would your organisation respond if 20,000 people tried to call you at the same time?

Consider the OWASP AppSensor

There’s some great thinking about how to get applications to think on a system-wide basis in the OWASP AppSensor project.

Leave a Reply

Your email address will not be published. Required fields are marked *