Tesco Bank — debit-card fraud weekend

What happened

Over the weekend of 5 to 6 November 2016, approximately 9,000 Tesco Bank current-account holders saw unexplained debits leaving their accounts. The transactions were small in individual value but numerous, and they were concentrated in card-not-present purchases processed through overseas merchants. By Monday morning Tesco Bank had suspended all online debit-card transactions on current accounts, effectively halting legitimate customer card spending while it investigated. The total amount fraudulently withdrawn was £2.26 million; the bank refunded the full amount to all affected customers.

The FCA opened an enforcement investigation. In 2018 the FCA published its final notice fining Tesco Personal Finance plc £16.4 million — reduced from a higher figure for the bank’s cooperation and remediation — making it the first FCA enforcement action specifically for a bank’s failures in relation to a cyber-attack, rather than for broader conduct or prudential failures.

The FCA’s published final notice is unusually detailed and remains one of the most instructive regulatory documents in UK financial cybersecurity because it explains precisely what went wrong: the specific card-number predictability pattern, the specific authorisation system gap, and the specific failures in Tesco Bank’s monitoring and response that allowed the attack to run for an entire weekend before the bank acted.

How it worked

The FCA’s final notice identified two interlocking vulnerabilities that the attackers exploited in combination.

First, Tesco Bank’s debit card numbers were issued in a pattern that was algorithmically predictable. The FCA found that card numbers within a particular issuance block followed a sequence that meant an attacker who obtained a small number of genuine Tesco Bank card numbers could generate valid-range candidate card numbers for other accounts. While the specific technical details of the pattern were redacted in the published notice, the principle is well understood in payment-card security: card numbers should be issued from a cryptographically random distribution within the allowable BIN (bank identification number) range, not from an incrementing or otherwise guessable sequence.

Second, Tesco Bank’s online banking system contained a flaw in the authorisation logic for a specific category of card-not-present transaction. For certain types of international point-of-sale transactions, the system did not validate one or more of the standard card verification fields in the same way that it validated domestic transactions. This gap meant that an attacker using algorithmically generated card numbers — which would not have the correct CVV values, since those are independently generated and non-deducible — could still obtain authorisation for the fraudulent transaction type, because that specific authorisation path did not verify the CVV.

The combination of predictable card-number generation and an authorisation path that did not require the full set of verification fields meant that an attacker could construct large volumes of plausibly-authorised fraudulent transactions against Tesco Bank accounts without needing to have stolen real customer card data. The attack was, in this sense, a product design flaw rather than a data breach — no customer data needed to be stolen in advance.

Tesco Bank’s monitoring systems did not identify the volume and pattern of the weekend’s transactions as anomalous quickly enough to halt the attack during the Saturday and Sunday window. The bank’s fraud-detection controls were not calibrated to the specific signal of high-volume card-not-present transactions across a large number of accounts in a short time period. The FCA’s notice cites the bank’s failure to respond to the attack more rapidly once the transactions were visible as a distinct failure from the underlying product vulnerability.

Timeline

• Before November 2016 — Tesco Bank issues debit cards using a predictable card-number generation pattern; an authorisation gap exists in its online banking system for certain international card-not-present transactions.
• 5 November 2016 (Saturday) — Fraudulent transactions begin; approximately £2.26 million is withdrawn across approximately 9,000 accounts over the weekend. Tesco Bank’s fraud-monitoring systems do not escalate the activity during the Saturday window.
• 6 November 2016 (Sunday) — Fraudulent transactions continue; customers begin contacting the bank about unrecognised transactions.
• 7 November 2016 (Monday) — Tesco Bank suspends online debit-card transactions on current accounts; notifies regulators including the FCA and FPS (Faster Payments Scheme).
• November 2016 — Bank refunds all 9,000 affected customers in full. FCA investigation opens.
• October 2018 — FCA publishes final notice and announces £16.4 million fine — the first UK financial-sector fine specifically for cyber-attack response failures. The underlying product vulnerabilities have been remediated.

What defenders should learn

The Tesco Bank incident is the canonical UK example of a fraud attack that required no data theft, only design exploitation. The attackers did not need to steal customer card data, credentials, or any other specific information about individual Tesco Bank customers. They needed only to understand the card-number generation pattern and the authorisation logic gap well enough to construct transactions that the system would approve. That means the normal defences against data-theft-based fraud — strong authentication, monitoring for credential abuse, data loss prevention — were beside the point. The relevant controls were in payment-system design and fraud-detection calibration.

Card-number generation is a concrete and regulatable design choice. Cards should be issued from cryptographically random distributions within the allowable BIN range. Sequential, incremental, or otherwise pattern-following issuance creates an enumerable attack surface. This is not an obscure principle: it is a standard recommendation in every major card-security framework and has been so for years. The presence of a predictable issuance pattern in a bank’s card-generation system in 2016 indicates that the design requirement was either not specified, not tested, or not verified at issuance.

The authorisation system gap is the second design lesson. Every payment authorisation path — domestic, international, card-present, card-not-present, online, telephone — must apply the full set of available verification checks. Allowing a category of transactions to bypass CVV validation because it was convenient for the specific transaction type creates a path that attackers can identify and exploit. The business logic of payment authorisation systems should be reviewed specifically for verification-field completeness across every code path, not just the high-volume paths.

The fraud-detection calibration failure is the operational lesson. Tesco Bank’s fraud-monitoring systems were in place and running during the weekend; they did not escalate the attack pattern in time to stop it. Fraud monitoring needs to be calibrated for attack patterns, not just for individual-account anomalies. A large number of accounts each experiencing small, unusual card-not-present transactions simultaneously is a different signal from any individual account’s transaction history being anomalous — it is a population-level signal that requires population-level monitoring logic.

The FCA’s fine is significant not for its amount but for its precedential framing: it was the first time the UK’s financial regulator treated cyber-attack response failure as an enforcement matter in the same category as other operational risk failures. That framing — that a bank’s responsibility extends to having adequate cyber controls and incident response, not just adequate post-incident customer remediation — is now embedded in UK financial regulatory expectations.