Revolut says fraudulent information requests arrived through a legitimate government-agency email domain and resulted in customer data being disclosed to an unauthorised third party. I used to run a bank and built an earlier version of a regulator-as-user product. This incident made me revise one of the assumptions behind it.
What made the incident interesting to me is what did not happen. Revolut said its systems and customer funds were unaffected. Public reporting says the fraudulent requests used a legitimate government-agency domain. TechCrunch says identity/contact data and copies of passports or driving licences were exposed, and that the affected data may also have included verification selfies, account statements and transaction histories.
No exotic model failure is needed to explain the design problem. A convincing piece of evidence — the channel — acquired too much operational authority before the human, current capacity, mandate and scope were fully resolved.
That is the problem I want to make explicit and testable.
At Arival, I treated the regulator as a product segment rather than an external nuisance. An agency could exist as an entity, with named human representatives as sub-users. Bank-account functionality was disabled; the point was structured supervisory interaction.
Survived: regulatory interaction is a product problem: actors, objects, states, evidence, latency and auditability all matter.
Did not survive: using the working government email as the bootstrap root of trust. A legitimate domain can be evidence about the channel without proving the current human, their capacity or their mandate.
2026 revision: Regulator-as-user → authority-as-preverified-principal, with scoped virtual views and explicit mandate objects.
That sounded pragmatic: give less now, verify more later. It was also the same failure class with a smaller payload. Once an address, phone number, ID fragment or account detail leaves the bank, it is not provisional in any meaningful sense.
Government-domain match → provisional minimum disclosure while identity resolves.
Government-domain match → HOLD. Preserve / prepare / escalate internally. packet_out = null until principal + capacity + mandate + scope pass.
Out-of-band verification via a number sourced independently of the request.
Named principals + current capacity. Domain membership is insufficient.
While authority resolves: preserve, prepare, restrict deletion, escalate. Release zero PII.
Second human for passports, selfies and broad transaction-history releases.
Canonicalise → hash → sign → timestamp → bind to rule version and mandate object.
Where did the message travel? Necessary evidence, never sufficient authority.
Who is the named human/system? Verify independently.
Do they currently represent the agency in the relevant role?
What lawful power applies to this case, purpose and jurisdiction?
Which subjects, fields and time range may leave?
{
"request_id": "DW-2026-09-14-0041",
"channel_evidence": {"type":"gov_domain_email","status":"pass","role":"evidence_only"},
"principal": {"name":null,"verified_out_of_band":false},
"capacity": {"agency_id":null,"current":"unknown"},
"mandate": {"legal_basis":null,"case_id":null,"jurisdiction":null},
"scope": {"subjects":[],"fields":[],"time_range":null},
"state": "HOLD",
"packet_out": null,
"ai_override": false
}DATA_OUT :=
channel_evidence.valid
AND principal.verified
AND capacity.current
AND mandate.valid
AND scope.non_empty
AND required_human_approvals.complete
if irreversible(action):
deferred_controls(action) = ∅
HOLD.permits = [preserve, prepare_internal, restrict_deletion, escalate]
HOLD.forbids = [release_pii, export_kyc, disclose_tx_history]
ai_override = false// choose a trajectory
These are reference-model assertions. They become evidence only when the same invariants are enforced and regression-tested in implementation.
Revolut confirmed fraudulent requests sent from a legitimate government-agency email domain.
Revolut confirmed sensitive customer information was disclosed to an unauthorised third party.
Revolut said its systems and customer funds were unaffected.
TechCrunch says identity/contact details and ID document copies were affected; selfies, statements and transaction histories may also have been included.
My model: channel evidence became operational permission too early. This is not Revolut's published root-cause language.
A design response derived from LC01/LC02 — not a deployed Revolut or Arival control.
A synthetic disclosure desk. Professional red-teamers first. Then, case-by-case and under ordinary paid contracts, people with lived experience of fraud or social engineering generating attack paths a conventional compliance exercise may never imagine: urgency theatre, false capacity cues, scope inflation, the “helpful shortcut” after a refusal. No production PII. The product is not cheap labour. The product is adversarial knowledge.
Baseline: security, fraud and compliance specialists.
Post-conviction / post-release experts, paid normally, synthetic environment only.
Custodial setting only later, if HMPPS + ethics + security design make sense.
If you can design a synthetic request that crosses DATA OUT without complete principal + capacity + mandate + scope, the strongest response is not a defensive paragraph. It is a signed revision event and a new regression test.
Open the short news version