SpecterData minimisation is the principle that a service should collect only the data it genuinely needs to function, keep it only as long as it is needed, and use it only for the purpose it was collected for.
In the EU and UK it is a legal requirement rather than a preference. GDPR Article 5(1)(c) requires personal data to be adequate, relevant, and limited to what is necessary for the purpose. Article 5(1)(e) adds storage limitation, which is the requirement to stop keeping it once that purpose is served. Most organisations comply with the first and quietly ignore the second.
Data as a liability
Companies book collected data as an asset, and it behaves like one until the day it behaves like a loan coming due. Every record held carries ongoing costs that rarely appear on the same balance sheet: securing it, defending it, honouring access and deletion requests, and absorbing the fallout when it escapes.
The Equifax breach in 2017 exposed personal records for roughly one hundred and fifty million people, including national identifiers that cannot be reissued the way a card number can. The people affected were never Equifax customers and had no way to opt out of the collection, which is the part of the story that generalises. Most of the data held about you was collected by companies you have no relationship with.
Read breach disclosures with one question in mind. How much of what leaked was necessary to deliver the service? The answer is usually a small fraction. The rest was collected because storage is cheap and someone thought it might be useful later.
What over collection looks like in practice
- A date of birth required to create an account that has no age restriction, when an over eighteen checkbox would carry the same legal weight.
- A full home address for a service that delivers nothing physical.
- Contact list access requested for a feature that would work with a manual invite.
- Precise location logged continuously when the feature needs a city, or needs location only while the app is open.
- Server logs retaining full IP addresses indefinitely, when the operational need is measured in days.
What you can do as a user
- Give the minimum a form will accept and see what is actually enforced. Optional fields are frequently unmarked.
- Use a distinct email alias per service. It costs nothing, and it reveals precisely who leaked or sold your address when the spam arrives.
- Exercise your access rights. In the EU and UK, a subject access request under Article 15 compels disclosure of what an organisation holds about you, and the results are often startling. This is the mechanism that surfaced the Coutts file in the Farage case.
- Request erasure under Article 17 when a service is no longer in use. Deleting the account frequently does not delete the data.
- Delete dormant accounts rather than abandoning them, since an unused account is a live breach surface with nobody watching it.
What it means for people building things
- Ask what happens if you never collect a field. If the answer is nothing, the field is a liability with no offsetting benefit.
- Set retention periods at the point of collection and enforce them automatically, since manual deletion never happens.
- Truncate or hash identifiers in logs by default, because log files are the most commonly forgotten copy of everything.
- Keep analytics aggregate. Per user event streams are a behavioural dossier under a friendlier name.
Specter's policy
Specter collects only what is operationally necessary, stores it with user consent, and does not sell personal information. Since there is no KYC file, the most sensitive category of data in financial services is never created in the first place. The cheapest data to secure is the data that was never collected, and the only guarantee that survives a change of ownership is the absence of the data itself.