The whitepaper stays deliberately concise. The questions below arise every time the proposal is discussed, so they get a proper answer here instead of crowding the paper itself.
Yes, in the same sense that a bank is an attractive target because it holds money. The comparison that matters isn't "Databank vs. nothing," it's "one regulated Databank, audited and insured against breach" vs. "the same data already scattered, today, across thousands of companies with wildly uneven security practices." Databanking doesn't remove concentration risk — it replaces uncontrolled replication risk with regulated custodial risk, the same trade-off banking made with money centuries ago, with most of the relevant playbook (operational security, fraud detection, disaster recovery, regulatory audit) already worked out and ready to port across.
Some would. But the objection assumes incumbents can only lose under this model, and that isn't obvious. The organisations best placed to operate a Databank — by brand, by security expertise, by regulatory experience, and by the fact that they already perform parts of the function — are precisely today's incumbents. A retail bank already holds a detailed transaction history, already operates under custodial regulation, already runs fraud detection, dispute resolution and key recovery, and already gives customers a reason to trust it with something valuable. Its business is mostly the manipulation of bits already; extending custody from money to data is an expansion of an existing franchise, not a surrender of one. Apple already stores personal data in the cloud, masks email addresses, proxies web traffic, and intermediates purchases through Apple Pay — a spun-off Databank would repackage services it already markets as privacy.
For governments and healthcare providers the calculation differs but points the same way: storing and securing personal data is not their core business, it is a cost centre and a standing liability, and it is already widely subcontracted. Subcontracting it to a regulated Databank rather than to an ordinary cloud provider changes the legal arrangement, not the operating model — and moves breach liability off the public body. The realistic dynamic is therefore not uniform resistance but its opposite: whichever incumbent internalises the model first acquires a defensible, regulated position, and the others follow rather than be left holding the liability without the revenue. Paradigm shifts of this kind are rarely defeated by incumbents; more often they are carried by the subset of incumbents that decide to lead them.
Hundreds of millions of people already do. China's super-app model — WeChat and Alipay most prominently — folds identity, payments, mobility, ticketing, shopping, messaging and public services into a single data environment, and it is popular precisely because the integration is convenient. The same gravitational pull is visible in Western products: an Apple or Google account already spans identity, payment, location, photos, health and purchase history. The consumer appetite for a unified data environment is therefore not a hypothesis to be tested; it is an established fact of the last decade.
What is contested is not the integration but its ownership. In the super-app model the unified environment belongs to Tencent, Alibaba, Alphabet or Apple, and its convenience is inseparable from a single commercial — and, in some jurisdictions, state-accessible — controller holding the whole picture. Databanking keeps the integration and changes the owner: the same unified environment, held by a regulated custodian acting for the individual rather than by a platform acting for itself. The structural difference is the separation of custody from analysis. A super-app stores your data and mines it; a Databank may only store it, answer queries against it under the Owner's permissions, and log every access. Integration without a controller who profits from looking is the part that does not yet exist anywhere.
Most people won't, and shouldn't have to. The concern behind the question is permission fatigue — the well-documented failure mode of consent-based privacy law, where users faced with a decision at every site stop reading and click whatever clears the dialogue fastest. Cookie banners are the canonical example: a consent mechanism that technically informs and practically exhausts. Any model that asked people to make the same choice a thousand times over would reproduce exactly that failure. Databanks would instead offer a small set of permission templates — something like Maximum Privacy, Research Friendly, Healthcare Friendly, Advertising Enabled, Revenue Maximising — and most users would simply pick one and move on, the same way most people pick a bank account tier rather than negotiating its terms line by line. Anyone who wants granular, per-Requestor control still has it underneath the template, exactly as banking apps, LinkedIn, and most cloud platforms already expose both a simple default and an advanced settings panel for people who want it.
You could, in the same sense you could keep your savings in cash under a mattress instead of in a bank account. Custody alone was never really the service a bank — or a Databank — provides. What you'd be giving up is authentication, guaranteed availability, portability between providers, dispute resolution, regulatory compliance, statutory compensation handling when someone pays to query your data, and key recovery if you lose access. A Databank is closer to a financial institution than to a storage device, and self-hosting remains a valid option for anyone who only wants the storage part.
Probably not much per transaction — likely fractions of a cent or a penny per query, not a meaningful one-off payout. The model doesn't depend on any single payment being large; it depends on frequency, scale, and automation. The closest precedent is digital advertising itself, where individually tiny per-impression values aggregate into one of the largest revenue pools in the economy — the difference under Databanking is that a share of that flow reaches the person the data describes, rather than all of it staying with the platform. Sizing this properly — against existing ad-tech, data-brokerage, healthcare data, and research-access markets — is future work, not something the whitepaper claims to have already calculated.
Not directly, no. Some categories of data — credit, medical, and criminal history among them — are owned but not directly editable: the Owner cannot unilaterally delete or mask part of the record. What ownership does guarantee is visibility and accountability: Owners can see this data in full, together with an audit trail of how each entry was generated, and can flag errors or request corrections through their Databank. That's already a meaningful improvement over today's credit or medical histories, which are largely opaque to the individual and come with no audit trail at all.
No, this it changes the access path, not whether lawful access exists. Today a warrant or equivalent legal instrument is usually served directly on whichever company happens to hold the data. Under Databanking it would be served on the Databank instead, through a single regulated access mechanism rather than an ad hoc one per company. Because every Databank already logs every access to an audit ledger, lawful requests become more accountable and traceable than today's fragmented landscape, not less. How a warrant becomes a computation — and why even a well-governed surveillance database does not provide the same property as non-disclosure — is developed in the law-enforcement case study.
Several mechanisms handle this without needing a single, universal answer. Data can sit in a joint account, shared by the relevant parties under rules they agree on. It can be ceded to one of the parties, who becomes the sole Owner of record. It can be transferred to the Databank account of an entity rather than an individual — a company, a charity, a trust — when the data properly belongs to that entity rather than to any one person. And ownership itself can be transferred between accounts as a discrete event: the data plus its access restrictions packaged together as a single object, with a hash of that package recorded on a blockchain as a tamper-evident record of who owned what, and when, without putting the data itself on-chain.
Public-by-design content fits the same model with one extra setting. A video, like any other data, sits in its creator's Databank account, but with public access permissions instead of restricted ones. A third party — a subsidiary or contractor of the Databank, playing the role a video platform plays today — accesses and streams it on request, paying a micropayment per view that's shared with the creator. The difference from today's model is who gets paid and how: instead of Alphabet monetising the view through inserted advertising, the Databank ecosystem monetises it directly through the access fee, with a share flowing back to the person who made the content.
Yes, and it answers a different question from the identity and age items above. Those concern proving a fact about yourself without handing over the evidence behind it. This one concerns holding an accountable account without disclosing any fact about yourself at all. A service does not need to know who a user is. It needs to know that the same person is returning, and that the account is answerable to someone.
A Databank can issue a service-specific pseudonymous identifier: stable for that service, different for every other, and unlinkable across them. The service authenticates against the Databank instead of holding its own password, email address and recovery data. Checking whether an account is banned becomes the same question as checking whether it already exists.
The identifier is issued under a regulated pseudonymisation scheme anchored to the authoritative identity record rather than to the custodian, so that any licensed Databank arrives at the same identifier for the same person and service. Moving to a different Databank therefore returns the same identifier rather than a clean slate. Identifiers held by different services remain unlinkable, and the scheme has to be constructed so that a service cannot work backwards from an identifier to the person behind it.
Accountability therefore rests on the custodial relationship, not on Databanks circulating reputation about their account holders between themselves. That circulation would rebuild the profiling infrastructure the model removes, and the custody wall excludes it. A service's report of abuse is directed to the account, and its consequences are a matter between the individual and their Databank, or between the service and lawful process.
In the longer term, largely yes. That product category exists because every service keeps its own credential, and someone then has to keep track of hundreds of them. Remove the replication and the reason for the tool goes with it.
The replacement is not a single universal credential presented everywhere. The Databank is the trust root. The Owner authenticates to their own Databank using device-bound cryptography, a security key or a biometric, and the Databank then issues each service its own scoped assertion carrying the pairwise identifier described above. Nothing a service holds can be replayed against another service, and no service holds a secret belonging to the Owner at all. The component doing this is the identity service in the whitepaper's reference architecture, which is also where account recovery sits.
None of the machinery is speculative. WebAuthn covers the leg from the Owner to the Databank and became a W3C Recommendation on 25 August 2026; OpenID Connect or a successor covers the leg from the Databank to the service; FIDO already supports both synced and device-bound passkeys. Databanking does not propose to replace that substrate. It changes who sits at the identity provider end of it.
Internet identity is currently divided among at least six separate businesses, most of which have their own answer elsewhere on this page. Password managers hold credentials. Google and Apple provide federated login. KYC firms establish legal identity. Age-verification vendors attest to age. Email providers serve as the de facto universal identifier. Data brokers assemble an inferred identity nobody asked them for. Each solves one fragment, each keeps its own copy of whatever it touches, and none of them answers to the person being described.
Under Databanking those fragments collapse into a single regulated custody boundary, and each Requestor obtains only the claim it needs. The closest thing that exists today is Apple's Sign in with Apple, which interposes a per-service address between a user and a website, and which the whitepaper treats as a genuine partial precedent. It stops short in the way any platform implementation must. The intermediary is the platform itself, its interest in the login is the profile behind it, and the arrangement cannot be taken anywhere else. Databanking puts a regulated custodian in that position instead: one that cannot read what it holds, and that the Owner is free to leave, taking the identity with them.
No, because a passport solves a different problem from the one Databanking addresses.
A passport, physical or electronic, is a low-friction credential. It gives its holder a simple way to present an identity issued by an authoritative institution. Replacing that with repeated facial, iris or fingerprint recognition would not remove the underlying identity infrastructure. Those measurements would still have to be checked against authoritative records of name, nationality and status, and the check would be more intrusive than the credential it replaced.
What Databanking changes is where the information behind the credential is held and how it is reached. The issuing government remains the authority for the passport and for the identity record beneath it. The Databank acts as the individual's custodial and intermediation layer for every subsequent use of that identity. A hotel, an employer or an online service asks the Databank the particular question it needs answered ("is this passport valid?", "does this name match the authoritative record?") and receives the answer, not a copy of the record.
The credential therefore survives. What ends is the proliferation of copies of the information behind it. Databanking is a change in custody and disclosure here, not a demand that a convenient document be swapped for a more intrusive authentication mechanism.
This is exactly the kind of query Databanking is built for, and it's a good concrete illustration of the model. Today, "know your customer" (KYC) checks mean every company you sign up with collects and stores its own copy of your face and your ID document — a live biometric and a government document, duplicated across every bank, dating app, and gig platform that asks for one. Under Databanking, the company instead queries your Databank account: it gets back a verified-identity link or token — "this is a real person, the document matches the face, here is a verification reference" — not the video or the document image itself. The company never holds your mugshot or your licence scan; it holds a pointer to a verification that your Databank performed once and can re-attest whenever a new Requestor needs it. One verification, reused everywhere, instead of the same sensitive biometric file copied to every company that happens to ask for it.
Yes, and it's arguably the strongest near-term application of the model. Platforms now have a live legal duty to check users' ages, and regulators are actively enforcing it — but every platform currently runs its own check from scratch, meaning the same ID document, face scan, or card gets handed to a different company each time. Under Databanking, the age fact is established once with a regulated custodian, and every later platform receives a yes/no predicate instead of the underlying evidence. Databanking doesn't replace the underlying verification methods regulators require — it replaces the need to repeat them on every platform. See the age-assurance case study for the regulatory detail.
Trusted Research Environments — data safe havens, secure analytics platforms, and the Five Safes framework they are designed around — already apply compute-to-data in production. The best known is OpenSAFELY, which runs against the primary care records of a large share of patients in England. Researchers submit code, the code executes where the data already sits, the analyst never sees an identifiable record, and the analysis code is published. Databanking uses the same mechanism.
The difference is scope and beneficiary. A TRE governs institutional access to a population: a research team applies, an ethics committee approves, and the safeguards protect the dataset and the people in it as a class. A Databank governs transactional queries about a single person, and its safeguards run to that person. The Owner sets standing permissions, sees an audit statement of who asked what, can revoke access, and receives a share of the access fee. A TRE lets approved researchers study NHS records without copying them. It is not built to let a retailer confirm that Alice is over 18 without keeping her date of birth, or to tell Alice that the retailer asked.
The two also control disclosure differently. A TRE relies on statistical disclosure control: a human reviewer inspects outputs for re-identification risk before release. That suits a few dozen research outputs a month rather than millions of automated queries a second. A Databank declares the budget in advance — each algorithm states how many bits its answer may disclose, and the boundary rejects anything larger. Bounding cumulative disclosure across repeated queries is unsolved, and is marked as unimplemented in the reference implementation.
Yes, because your email address would stop being a fact that every sender gets to keep. Email is a natural service for a Databank to absorb: the account already holds the identity, and the custodial model already provides the mechanism. Each sender is issued its own alias rather than the address itself, in the way today's hide-my-email features gesture at, so every message arrives tagged with the origin its alias was issued to. That changes what "unsubscribe" means. Today the link at the bottom of a junk email is a request to the sender's goodwill, and acting on it can do little more than confirm that the address is live. Under Databanking, unsubscribing is an instruction to your own custodian: the alias is revoked, or the sender is banned outright, at source, with no cooperation from the sender required. This is the same shape as the right-to-be-deleted case: the remedy executes on your side of the boundary instead of relying on compliance from the other side of it.
It promised it, but with the data on the wrong side of the wall. Databanking draws the opposite conclusion: personal data is precisely what should never sit on a replicated, immutable public ledger, where it can no longer be corrected, deleted, or meaningfully restricted. The data stays inside a regulated Databank; blockchain, where used at all, is optional infrastructure around it. The model requires no chain, no token, and no NFT, and works identically over conventional payment and audit rails. That is also the direction of the EDPB’s final blockchain guidance (July 2026): keep personal data off-chain, and put only carefully designed cryptographic proof material on-chain, where a blockchain is justified at all.
Within that constraint, a few narrow roles earn their place. The ownership-transfer record in the answer above is one: a hash of the transfer package on-chain, the data itself never. Smart contracts are another — as consumers of Databank outputs rather than holders of personal data, asking “is this person over 18?” and receiving a signed TRUE instead of a copy of a passport. Settlement of query micropayments could run on programmable rails, though nothing requires it to. An NFT can at most represent a licence or a receipt concerning data — never the data themselves, and never an authority that overrides law, Databank policy, or a withdrawn authorisation.
The most useful role inverts the usual pitch entirely: a Databank can periodically anchor a cryptographic commitment to its own audit log on an external chain, so that any later rewriting of its committed history becomes independently detectable. The blockchain doesn’t make your data public; it makes the custodian’s record-keeping tamper-evident. That question — who watches the custodian? — is developed as a research strand.