Revolut does not own a fleet of AI computers, and buying one is not the hard part — compute is rentable. What it already owns is harder to build and impossible to rent: a device-bound, attested key on tens of millions of phones, issued under a banking licence, revocable centrally, and already trusted for strong customer authentication. Enrolment at scale is the bottleneck in every sovereign-AI proposal. Here it is already solved, for a different purpose.
A home lab is not evidence that a bank can run its risk stack on one mini-PC. It is evidence about a different unit: a local, revocable, policy-bound node that does private work close to the data and escalates what it cannot or must not decide.
Can Revolut replace central AI with millions of local machines?
Can Revolut issue bounded, revocable, independently verifiable authority to software acting on a customer’s behalf — and have a third party who banks elsewhere accept the proof?
Four independent drafts of this thesis all placed identity, permissions and revocation in a central Revolut registry with a compliance dashboard on top. That is the standard enterprise identity answer and it works perfectly — inside the perimeter.
It stops working at the first company boundary. When a node at an SME acts toward that SME’s auditor, its non-Revolut bank, a supplier or a tax authority, the counterparty cannot query Revolut’s registry. “Revolut says this node was authorised” is a claim, not evidence. The counterparty must be able to verify, offline and after the fact, that a specific action fell inside a specific mandate that was valid at that moment — without being a Revolut customer and without trusting a dashboard.
A central registry makes this an internal control. A verifiable credential makes it a product that works where Revolut’s customers are not — which is the only version with a network effect.
Local model, OCR, retrieval, drafting, bookkeeping, document processing. Hardware varies: phone secure element, laptop, workstation, appliance. The root of trust is the attested key, not the silicon class.
Signed, versioned, expiring: what may be done, on what facts, to what cap, until when, what must be recorded, when to escalate. Solvers are implementation detail — no claim that law is fully formalisable.
Memory spilled locally where the machine allows; selected tasks routed to an approved pool when it does not. Routing is itself policy-controlled — where a task may go is part of the mandate, not a scheduler decision.
Every action carries a credential chain: who issued the mandate, to which key, under which policy version, revoked or not. Verifiable by a counterparty with no access to Revolut and no access to the node.
Tens of thousands, inside one legal entity, on managed devices. One authority pack, one escalation path, no external customer risk. This is where failure modes are discovered cheaply.
Where the thesis either earns money or dies. These customers already have documents, payroll, vendors and accounting to process, and they already deal with counterparties who are not Revolut — so they are also the first population that needs the proof layer.
Do not extrapolate a £2–4k workstation to tens of millions of people. The mass node is the phone that is already in the customer’s hand and already holds the key. A dedicated box is a premium slice, not the plan.
The route from an N=1 experiment to a product proposition is a sequence of increasingly expensive falsification tests, not a jump.
One knowledge worker or small regulated operator. Test authority packaging, local execution, logging, revocation, overflow — and whether an outside party can actually verify a trace.
Employees, or a handful of business accounts. One workflow, one authority pack, one hardware profile.
Over-the-air policy updates, telemetry minimisation, mixed devices, rollback, revocation latency, real service economics — and the first counterparty who is not a customer accepting a proof.
Only then: segmented rollout by jurisdiction, workflow and risk class.
Will any counterparty outside the issuer’s ecosystem actually accept a credential-backed trace, or do they demand a human signature anyway?
Is local plus overflow cheaper or more valuable than cloud-only after support, updates and hardware?
Can authority be versioned, signed, revoked and audited without turning every policy into a brittle formalisation project?
Does sovereignty, privacy or latency create willingness to adopt — or is this elegant and commercially unnecessary?