The bank scams costing victims billions have one thing in common: a verification step that lied

Revolut was named in more UK fraud complaints than any other financial firm, 3,242 in 2024 alone, and it was still top in the first eight months of 2025 with 1,875 new cases, ahead of Barclays and Monzo. In Spain, fraud complaints to the central bank rose 18% in 2025, then over 50% again in the first four months of 2026. In July 2026, Spain's Guardia Civil broke up a gang running Operation Fragmenta, sending fake bank texts, then phoning victims posing as bank staff to extract verification codes, with nearly 2,000 possible victims identified so far.

Different countries, different institutions, the same underlying failure. In every one of these cases, the victim authorised something. They typed a code, confirmed a payment, or approved a transfer. The fraud wasn't a system being hacked. It was a person being deceived about what they were actually approving, and the system had no way to tell the difference between informed consent and a lie that had worked.

What's actually happening, and what isn't

It's worth being precise here, because "bank scam" headlines get misread easily. In the large majority of these cases, the bank is not the one committing fraud. The criminal is a third party, posing as the bank, a delivery courier, a romance interest, or a family member in distress. The genuine, live debate is about something narrower but still serious: how well banks detect that an authorisation is happening under deception, how quickly they respond once it does, and how liability is shared when it goes wrong.

Revolut has argued that social media platforms carry real responsibility too, saying Meta accounted for 62% of the scams reported to it in the first half of 2024, since that's typically where the deception itself originates, before the victim ever opens their banking app. Under the UK's current regime, sending and receiving banks split liability for authorised push payment fraud 50:50, up to £85,000 per case. A BBC Panorama investigation separately raised questions about how Revolut communicated with victims after the fact. In Spain, a 2025 Supreme Court ruling against Ibercaja went the other way on a related question, holding that the burden of proof sits with the bank when a customer claims a transaction wasn't authorised at all, rather than deceived into authorising it.

Both of those are real, serious arguments. Neither one touches the actual mechanical failure that makes this kind of fraud possible in the first place.

The mechanical failure, and why it isn't new

A one-time code, a confirmation tap, a verbal "yes" on a phone call, these are all treated, by the systems that accept them, as proof that the account holder understood and approved the specific action taking place. That assumption is the entire vulnerability. A verification step only proves that someone who had access to a channel, a phone, a text message, a voice call, produced the right signal. It proves nothing about whether that person understood what they were actually signing off on.

This isn't unique to banking. It's the same failure mode that shows up anywhere a system treats "a human did something that looks like approval" as equivalent to "a human gave informed, specific consent to this exact action." A confirmation dialog that anyone can click through is not an authorisation boundary. Neither is a verification code read out over the phone to someone the victim has been told, falsely, is their bank's fraud team.

We've written before about this same category of problem from the AI side: why separating "an action was proposed" from "a human genuinely authorised this specific action" has to be a structural property of a system, not a UI nicety that can be deceived or skipped. The parallel to social-engineering fraud is direct. A scammer doesn't need to break a bank's security. They need the victim to perform a real, valid authorisation step, while lying about what it's for. No amount of stronger encryption or better fraud-scoring fixes that, because the authorisation itself is genuine. What's false is the context around it.

What would actually help

None of this is a pitch for a single product fixing bank fraud, that would be a wildly overstated claim about a problem this serious and this well-studied. But the design principle generalises past banking, and it's worth stating plainly: an authorisation step should carry with it a verifiable, specific record of what was actually being approved, not just that an approval-shaped signal was produced. "The customer entered the code" and "the customer understood they were authorising a £12,000 transfer to a new payee, initiated by someone who had just told them their account was compromised" are very different things, and most current systems cannot distinguish between them after the fact.

That's the same principle behind why Mickai's AI authorisation is built around an immutable record of what was actually proposed and approved, sealed independently of the system that executed it, rather than trusting a confirmation step to have meant what it looked like it meant. The banking cases above aren't AI failures. But they're the same category of design problem, and it's one worth taking seriously anywhere a system asks a human to approve something consequential.

Sources

• UK Tech News, 'Revolut ramps up Meta fraud liability demands amid major WhatsApp scam losses', uktech.news (31 March 2025).
• Yahoo Finance, 'Revolut named in more fraud complaints than any major UK bank, report finds', uk.finance.yahoo.com.
• Payment Expert, 'APP fraud disputes, Revolut UK', paymentexpert.com (2 October 2025).
• Vixio, 'Communication breakdown: further questions raised over Revolut's fraud response', vixio.com.
• The Olive Press, 'Bank scammers in Spain robbed at least 2,000 victims thanks to bogus text messages', theolivepress.es (22 July 2026).
• Murcia Today, 'Spanish banks must pay up: Supreme Court rules in favour of fraud victims', murciatoday.com.
• BioCatch, 'Report 2026: digital banking fraud trends in Spain', biocatch.com.