A Revolut data breach claim surfaced on July 25, 2026, when a threat actor listed a database on a cybercrime forum, advertised as 75 million customer records. Researchers at Cybernews obtained and examined the published sample. Revolut, for its part, has said it sees no indications of any breach.

Nothing has been confirmed either way. That’s precisely what makes this Revolut data breach claim useful as a case study. Most security work happens in exactly this state. A claim exists, the evidence is partial, and the vendor denies it. Someone still has to decide what to do before anyone knows the real answer. The technical question here isn’t whether Revolut was breached. It’s what the artefacts themselves can actually tell you.

What Is Actually on the Table

The seller published a sample of just over 100 records across four CSV files, with a fifth file surfacing later. The fields reported are unusually rich.

Card data includes last four digits, card type, expiry dates, and status flags such as active, blocked, and frozen. Credentials were hashed with bcrypt or argon2id, alongside timestamps recording when each password was last rotated. Identity and account data is broader still. It covers emails, full names, phone numbers, country of residence, addresses, currency, registration IP address, subscription plan, KYC status, an internal risk score, last-activity timestamps, monthly spend, and lifetime top-up. Device data includes device models, operating systems, and timestamps. The fifth file, meanwhile, reportedly contains bank account numbers, user IDs, and SWIFT codes.

The newest records in the sample date to around May 2025. Researchers found no link to previously documented breaches, and noted the presence of referral programme flags.

Revolut’s position, given to Cybernews and then updated after publication, is direct on this point. It checked the user and card identifiers in the alleged records against its own systems. None correspond to valid or genuine Revolut identifiers. The review is ongoing.

Signal One: The Price Is Wrong

The listing is advertised at $500. This is the strongest single indicator in the whole affair, and it doesn’t require access to anything.

Pricing on criminal markets isn’t sentimental. Fresh, validated financial records with card data attached command real money, because they convert directly into fraud. A genuine, exclusive dump of 75 million banking records from a live institution would be priced in the tens of thousands at minimum. It would more likely be sold privately, too, rather than listed openly on a forum.

Five hundred dollars, by contrast, is combolist pricing. It’s what you charge for aggregated material other people already have, for stale data, or for something you can’t substantiate. Either the seller isn’t confident in the goods, or they already know the buyer pool values them at close to nothing.

Signal Two: The Number Is Too Round

The second red flag in this Revolut data breach claim is arithmetic. Revolut publicly reports around 75 million retail customers. The listing claims exactly 75 million records. That match should raise an eyebrow on its own.

Real dumps don’t equal a company’s total customer count. Instead, they equal whatever the attacker actually reached. That might be one table, one shard, one export, one misconfigured bucket, or one compromised admin session. The resulting figure is arbitrary and untidy as a result. That’s exactly why genuine disclosures tend to produce numbers like 50,150, not clean round ones.

A record count that exactly matches a headline marketing figure is a number that was chosen, not counted. It suggests the seller reached for the company’s own public statistic to size their claim.

Signal Three: The Schema Doesn’t Look Like a Bank

This is the most interesting part technically, and it cuts in an unexpected direction.

Look at what’s in the field list. Subscription plan, KYC status, risk score, monthly spend, lifetime top-up, last-activity timestamp, device model, operating system, registration IP, referral flags. Now look at what’s thin instead: card data limited to last four digits, type, expiry, and status.

That’s not the shape of a core banking ledger. Rather, it’s the shape of an analytics or growth data mart. This is the kind of denormalised table assembled to answer questions about customer segments, activation, and referral performance. Lifetime top-up and monthly spend are aggregate metrics, not transaction records. Similarly, risk score and KYC status are decision outputs, not the underlying evidence behind them.

Suppose the data is genuine. Then that schema points away from a core systems compromise, and toward something adjacent instead: a business intelligence environment, a marketing or CRM platform, a data pipeline, or a third party with a feed. Aggregated warehouses are consistently softer targets than the systems they draw from. They also routinely hold a wider slice of customer attributes than any single production service does.

Suppose instead that the data is fabricated or assembled. In that case, this same schema is exactly what you’d expect from someone stitching together material from older breach compilations, then dressing it up with plausible-sounding internal fields.

The schema alone doesn’t settle it. It does, however, tell you which of the two stories to test first.

Signal Four: What the Identifier Check Proves, and What It Doesn’t

Revolut’s most substantive technical statement, in this Revolut data breach claim, is that the user and card identifiers in the sample don’t correspond to valid or genuine identifiers in its systems.

That’s a real check, it’s fast to run, and it’s the right first move. When the internal identifiers in a claimed dump don’t resolve against a company’s own ID space, the data almost certainly didn’t come out of the system that issues those identifiers.

What it doesn’t rule out is worth listing precisely, because this is where these disputes usually turn. It doesn’t rule out data from a period predating an identifier migration, for instance. Nor does it rule out data from a third-party processor or partner that maintains its own identifier space. An aggregation is also still possible, where real personal data from multiple sources was assembled and fitted with invented identifiers. And finally, it doesn’t rule out someone transforming or truncating identifiers before publishing the sample, which sellers frequently do to stop buyers from validating the goods for free.

The check strongly suggests the sample wasn’t lifted intact from Revolut’s production identifier space. That’s a narrower claim than “no breach occurred,” and it’s the claim the evidence actually supports.

An Inconsistency Worth Noting

Revolut’s initial statement described the listing as containing no record count, no sample, and no technical detail. Nothing, in other words, that substantiates the claim.

The listing contains a record count, though, and researchers examined over a hundred sample records across four files. Either the statement was drafted against a different post, or it was issued before the sample was located. It’s a minor thing on its own. Even so, response accuracy is part of response quality. A statement that can be checked and found wrong on a verifiable point weakens the statements around it that can’t be checked as easily.

Why “No Indications of a Breach” Is a Weak Sentence

This isn’t specific to Revolut, or to this Revolut data breach claim in particular. It’s a structural weakness in the phrase itself, and it shows up in nearly every incident of this type.

Absence of indications is a statement about detection coverage, not about what actually happened. It means the telemetry that exists, over the retention window that exists, hasn’t surfaced a match for the patterns being searched. Consider the possibilities. If the data left through a business intelligence export in early 2025, the relevant logs are likely outside retention entirely by now. A third-party leak wouldn’t show up either, since that data was never in the company’s own telemetry to begin with. And if it left through legitimate credentials running a legitimate-looking query, there may be nothing anomalous to find, even with perfect logging.

The stronger version of that same statement is specific. It sounds more like this: we checked these identifier spaces, over this window, using these data sources, and found no correspondence. Revolut’s follow-up statement on the breach moved in that direction. The initial one didn’t.

The Part That Doesn’t Depend on the Answer

Here’s what makes this Revolut data breach claim worth writing about, even if the whole thing turns out to be fabricated.

Look again at that field list, from the point of view of someone building a pretext. Full name, email, phone, address, subscription tier, device model, operating system, last four digits of the card, card status, and recent activity timing.

That combination is a social engineering kit. Picture the call. A caller knows your name, your plan tier, and the last four digits of your card. They know your card is currently frozen, and the exact model of phone you use. That doesn’t sound like a scammer. It sounds like the fraud team. The partial card data isn’t dangerous because it can be used to transact. It’s dangerous because it’s the shared secret most people accept as proof that a caller is legitimate.

That risk, in fact, is identical whether the data came from a breach, from an aggregation of five older breaches, or from a partner’s compromised warehouse. Provenance matters enormously for the institution’s remediation, and for attribution. It matters not at all, though, to the person receiving the phone call.

That’s the practical conclusion. Attribution and containment are one workstream. Assuming the data is live and adjusting what your support channels treat as proof of identity is another. Only the second one is on a clock that’s already running.

Talk to our team about breach verification and fraud-channel hardening → TALK

Frequently Asked Questions

Was there a real Revolut data breach in July 2026? It’s unconfirmed. A seller listed 75 million records on a cybercrime forum on July 25, 2026, priced at $500. Revolut says the sample’s identifiers don’t match its own systems, and its review is ongoing. Several technical signals, including the price and the record count, point toward the data being aggregated or fabricated rather than freshly stolen from Revolut’s core systems.

Why does the $500 price matter so much? Because pricing on criminal markets reflects real confidence in the goods. A genuine, exclusive dump of 75 million live banking records would sell for tens of thousands of dollars, or more likely be sold privately rather than listed on an open forum. A $500 price tag is typical of stale, aggregated, or unverifiable data.

What does it mean that the data doesn’t match Revolut’s identifier system? It means the sample likely wasn’t pulled directly from the production system that issues Revolut’s account and card identifiers. It doesn’t rule out the data coming from an older breach, a third-party partner, or an aggregation of multiple sources with invented identifiers stitched on.

Is this connected to Revolut’s 2022 data breach? No direct link has been found. Revolut disclosed a breach in September 2022 affecting 50,150 customers, caused by a targeted social engineering attack, and reported to Lithuania’s data protection authority. Researchers found no evidence connecting the July 2026 listing to that earlier incident.

Why should people care if the data turns out to be fake? Because the field list itself- name, phone number, partial card details, card status, and device model- is enough to build a convincing fraud pretext regardless of where it came from. Anyone receiving a call using these details should treat it as a red flag, whether or not Revolut’s systems were ever actually breached.

References

Primary reporting and sample analysis: Cybernews, “75 million Revolut records allegedly for sale: here’s what our researchers found,” July 27, 2026, updated July 28, 2026. Includes the field inventory from the published sample and Revolut’s statements. cybernews.com/security/revolut-data-breach-75-million-records

Prior incident, for context: Reporting on the September 2022 incident affecting 50,150 Revolut customers, attributed to a social engineering attack and disclosed via the Lithuanian data protection authority. bankinfosecurity.com/digital-bank-revolut-confirms-customer-data-breach-a-20117

Read More Here