To ask a company to erase your personal data, you currently have to hand over that very data — enough of it, at least, for the company to find your record. Databanking removes the paradox: the match happens inside the sandbox, and nothing comes out but a yes or a no.
Every existing route to deletion starts with disclosure. A GDPR erasure request must carry enough identifying detail for the controller to locate you in its systems. Commercial removal services such as DeleteMe or Incogni inherit the problem rather than solve it: they become custodians of their subscribers' personal information in order to send it, on their behalf, to hundreds of data brokers.
Even the most ambitious regulatory answer to date gets only halfway there. California's Delete Act platform, DROP, live since January 2026, lets a resident issue a single deletion request that reaches more than 600 registered data brokers — a real step forward, and one that already adopts half of this mechanism: the lists brokers download contain hashed identifiers, not raw ones. But a deterministic hash of an email address or phone number can be reversed by simply hashing candidate identifiers, and the matching itself happens inside each broker's systems — unlogged, unbounded, and invisible to the requester. A deletion list, even hashed, remains a testable register of precisely the people most concerned about their privacy.
An Owner instructs their Databank to broadcast an erasure request. Each receiving company gets two things, neither of which is the data itself:
For each candidate record, the company asks the sandbox one question: "does this record match this user?" One bit comes back. On a match, the company deletes its record. The company's data and the Owner's data meet only inside the sandbox — the company never learns anything beyond yes or no, and never receives the data it is being asked to delete. The ingredients are not speculative: private set intersection and privacy-preserving record linkage are established, well-studied techniques.
A dishonest company could try to run the protocol in reverse — using match queries as an oracle to find out whether a given person appears in its files, or to link records it shouldn't. The answer is the same discipline that governs every sandbox query under Databanking: match queries are authorised by the Owner, logged and visible in the Owner's audit trail, paid per query, and constrained by the same bit budget as every other question. Match queries are also restricted to candidate records that actually match the fingerprint — the sandbox can check this before answering — not arbitrary identities supplied by the company. Probing at scale is expensive, leaves a trail, and yields one bit at a time.
The Databank can confirm the match; it cannot reach into the company's systems and verify the deletion. That gap is real — and it is exactly the gap every current mechanism has too. DeleteMe and Incogni rely on brokers honouring requests; DROP backs its requests with penalties of $200 per request per day for non-compliance. Deletion is enforced by legislation, not by protocol, under Databanking as well. What Databanking changes is everything up to that point: the request itself no longer leaks the data it asks to erase.
This case study matters beyond its own use case. Any proposal to restructure data custody faces the question: how do we get there from here? Erasure-by-fingerprint is a concrete answer. Opening a Databank account would naturally be followed by one broadcast request — delete my data everywhere else — turning each new account into a step in the migration from today's regime of dispersed copies to the custodial one.