Case study

Investigate the crime. Don't hand over everyone's movements.

Police sometimes have a legitimate reason to search personal data without the individual's consent. That does not explain why answering one authorised question should require giving anyone — a police agency or the company supplying its tools — access to everybody else's movements. Under Databanking, the warrant authorises a computation, and the computation is all that runs.

A camera observation becomes a movement database

An automatic licence-plate reader records something apparently simple: a vehicle, a place, a time. One observation reveals little. Millions of observations, accumulated across a camera network, reveal where vehicles travel, which places they repeatedly visit, and which other vehicles tend to appear alongside them. And location history, as argued elsewhere on this site, is among the most sensitive data there is. Nor does modern analysis have to begin with a known suspect: in August 2026 WIRED reported on a system that layers police and commercial records over a nationwide licence-plate network and supports searches beginning not with a plate or a person but with a location, a period of time, and a pattern of behaviour.

Such a system can answer increasingly broad questions about a population because the underlying observations have already been collected into queryable infrastructure. Access controls, retention limits and audit logs can constrain how that infrastructure is used. They do not change its architecture: the data have already crossed the boundary.

A legitimate investigation

Suppose the police actually need an answer. A serious robbery takes place shortly after two in the morning; CCTV shows a dark SUV leaving the area, registration unreadable. Investigators obtain the legal authority required to search vehicle observations around the scene, and their question is narrow: which dark SUVs were observed within 500 metres of this location between 01:55 and 02:10?

There is no need to deny investigators that capability. The question is what must happen to everyone else's data in order to provide it.

Collect first, control access later

The conventional architecture answers by accumulation. Roadside cameras observe continuously; the observations are transferred to infrastructure operated by a police agency or a surveillance vendor; records are retained for later searching; an authorised investigator queries the accumulated database; matches are enriched from registration records, police systems and commercial identity sources. Security controls determine who may use the system, and audit logs record what they did. But an investigator authorised to ask one legitimate question is operating inside infrastructure capable of answering many others.

The central privacy problem therefore exists before any particular search is abused: a narrowly justified investigative capability has been implemented by creating a broadly queryable record of the population.

Move the question to the data

Under Databanking, retained vehicle observations would sit within regulated custodial infrastructure — held by custodians that, like any Databank, are structurally barred from analysing what they hold for their own benefit. The camera operator can still perform collection and narrowly defined processing; what it does not acquire is unrestricted analytical rights over the resulting movement records. And the legal authority, rather than being served as a demand for records, becomes part of the executable access policy — the warrant defines the computation the sandbox will permit:

Location
specified crime scene, 500 m radius
Time window
01:55–02:10
Predicate
vehicle_type = SUV, colour = dark
Permitted output
matching vehicles only
Expiry
end of the authorised investigation

The authorised query executes inside the relevant sandboxes — the same query lifecycle walked through in the worked example, under a different legal basis. The observations themselves never move into an investigator-controlled database. If three vehicles satisfy the predicate, the system returns three results, and the output is counted and logged like any other bit-scarce answer: not every vehicle observed in the area, not those vehicles' movements outside the authorised place and time, and no interface from which an entirely different population search can simply be typed.

Identification can be a separate operation. The first result need not contain the registered owners' identities at all: it can return opaque, case-specific vehicle tokens, and where identifying one of those vehicles becomes necessary and legally justified, a second authorised computation resolves that token. Search and identification become separable privileges rather than a single all-or-nothing act of disclosure. And the audit ledger records the whole of it — who authorised the computation, for which case, what predicate was executed, what result was permitted, what actually crossed the boundary, and whether any subsequent identification was authorised.

Spelled out step by step, this may look cumbersome. In operation it is the opposite: authorisation, execution and audit are functions of the underlying Databanking software framework, not additional paperwork. Once the legal authority is issued, the computation runs at machine speed, and a routine check returns as fast as the database query it replaces.

Warrant-to-compute

This changes what lawful access means. A conventional warrant or disclosure order operates, conceptually, as give the investigator the records satisfying these conditions. A Databanking-compatible authority operates as execute this computation over the relevant records and return only this specified result — warrant-to-compute rather than warrant-to-disclose. The investigator still obtains everything the legal process entitles them to obtain. What they do not automatically acquire is possession of the surrounding personal data. This is the "single regulated access mechanism" of the FAQ, given its full form.

Finding witnesses without identifying anyone

Data minimisation does not have to mean analytical incapacity. Sometimes constraining the output changes the workflow itself — and the constrained workflow still achieves the objective.

Consider a different investigation. Police want to reach potential witnesses who regularly travel through a neighbourhood and may have seen an incident. A conventional movement database answers by returning a list of vehicles and resolving them into names and home addresses. Yet identification is not actually necessary for the task. A Databank could identify the potential witnesses internally and pass each of them a mediated request: police investigating an incident near this location believe you may have relevant information; if you wish to assist, you can contact the investigating team here. Those who come forward, come forward. About those who decline, the police learn nothing. And the objective, reaching possible witnesses, has still been achieved.

Why access controls are not enough

Surveillance vendors can and do add governance. The operator of the network described above now publishes a policy with a seven-day default retention for licence-plate data, audited searches, mandatory case codes, misuse detection and automatic lockouts. Those controls matter, and they answer real questions: who may search the database, how long records are retained, whether improper searches can be detected afterwards. Databanking asks an earlier question: why does the investigator — or the vendor — need general access to the database at all? Where a narrow computation satisfies the legitimate purpose, access to the surrounding records is unnecessary. Even serious governance safeguards do not provide the same property as non-disclosure of the underlying data. That is the difference between controlling possession and avoiding it.

Not every query should be possible

Different investigative operations reveal very different amounts of personal information, and a Databanking regime can price that difference into the access policy itself. A stolen-vehicle hotlist check might run immediately at the camera. A bounded search around a crime scene requires documented investigative authority. Resolving an anonymous result into an identified individual requires a further authorisation. A pattern-of-life search across weeks of one person's movements requires substantially greater justification, and independent authority. And an open-ended instruction — find suspicious people in this area — need not be an available computation at all. This is the fundamental difference between policy enforced around a general-purpose analytical system and policy expressed in what the system can compute.

Data about you, not only data from you

This case also shows the full scope of the custodial model. A licence-plate observation is not deposited by the driver; it is generated by somebody else's sensor, and the same is true of facial recognition, inferred location, behavioural profiling, and a growing share of AI-derived personal information. The Databanking model therefore concerns not only information deliberately supplied by the individual: it encompasses the appropriate classes of observed and derived personal data as well — data about an individual, not merely data obtained from one. Anything narrower would leave an obvious loophole, since an organisation could escape custody simply by observing or inferring the information itself.

How externally generated records are routed into custodial infrastructure — by registry-mediated opaque routing, encrypted deposits, or a separately regulated shared custodial domain — belongs to the technical architecture rather than to this page.

Lawful access is not commercial access

Police access differs fundamentally from an advertiser or insurer querying a Databank. Where an investigator has valid legal authority, the individual cannot refuse the computation, and it would make no sense to pay a data dividend for being investigated. Databanking therefore allows a distinct lawful-access pathway, separate from consensual and commercial queries. The governing principles are unchanged — minimum necessary input, minimum necessary computation, minimum necessary output, purpose limitation, independent authority where required, complete auditability — but the legal basis for the computation is public law rather than consent or contract.

The architectural difference

The same legitimate question; radically different data exposure.

Conventional surveillanceDatabanking
Population observations, continuously collectedObservations held under regulated custody, barred from in-house analysis
Centralised into a queryable databaseLegal authority expressed as an executable computation
Investigator granted access to the databaseComputation executes inside the custodial boundary
Search, enrichment and identification in one stepMinimum authorised result returned; identification separately authorised
Records disclosed and retained by the investigatorAudit ledger records what ran and what crossed

The difference is not whether useful analysis can happen. It is where the analysis happens, what leaves the boundary, and who ever possesses the underlying data. Authorise the question, not possession of the dataset. Bring the computation to the data. Return the result — not everybody else's records.

← Back to the case studies