Why document KYC creates a honeypot — and what credential-native KYC does instead

In September 2026, Revolut told a group of customers that copies of their identity documents, the selfies they took to open their accounts, and their transaction histories had been handed to criminals. Nobody broke into Revolut's systems. The data was requested, and the request was fulfilled.

What happened

According to Revolut's notice to customers and subsequent reporting, an attacker sent requests for customer information from a legitimate government agency email domain. Italy's government later told parliament that a certified email address tied to a local Interior Ministry office had been compromised, and that Revolut had provided the data of 680 customers. Because the messages carried valid domain authentication, Revolut said they were fulfilled "under the reasonable belief that it was an authentic government agency request."

What went out was the full KYC file: names, dates of birth, addresses, phone numbers, copies of passports or driving licences, verification selfies, IBANs, account statements, and transaction histories.

The file is the vulnerability

It is tempting to treat this as a process failure: verify legal requests more carefully and move on. That is necessary, but it misses the structural point. Lawful data requests are an access path every regulated institution has to honour. Support staff, vendors, and backups are others. Any path that can reach the file will eventually be used by someone who should not.

Document KYC guarantees there is a file. Every verified customer leaves a passport scan and a selfie behind, and that file is valuable precisely because it was collected: it is everything a fraudster needs to impersonate someone convincingly. A leaked password can be changed. A leaked passport scan stays useful for years. And because each partner in a payment chain runs its own checks, the same file exists at the payout platform, the on-ramp, the off-ramp, and the bank. That multiplication is described on The Problem.

What credential-native KYC does instead

Credential-native KYC never collects the document. The person presents a government credential from a wallet on their phone, such as DigiLocker, a state mobile driver's licence, or an EUDI Wallet. The institution asks for specific attributes, the person approves, and the institution receives those attributes with the issuer's signature attached. The signature proves they are authentic. Nothing else crosses the wire.

Record-keeping obligations do not disappear. Under the US CIP rule, for example, an institution keeps the identifying information it collected and a description of how it verified it, not a copy of the document. A signed attestation satisfies that cleanly. What is gone is the passport scan and the selfie, the two artefacts that made the Revolut file worth stealing.

With credential-native KYC there is no passport scan on file to hand over. A forged request, a compromised inbox, or a careless vendor can only expose what exists. See the side-by-side with legacy KYC for how the data trail compares at each institution.

Minimisation is now possible, not just advisable

Data minimisation has been good advice for years, but with documents there was no way to follow it: the scan contains everything, so you store everything. Credentials change that. In the US, regulators confirmed in September that government-issued digital credentials satisfy the CIP rule. In the EU, payment institutions must accept the EUDI Wallet by December 2027.

You cannot lose what you were never required to keep. That is what Syntex is built on.