Fraud and AML say keep it for years, privacy says delete it. How do you build a system that satisfies both?

The two obligations are not aimed at the same data

The argument stalls whenever both sides talk about "the customer record". A retention obligation in an anti-money-laundering or financial-records regime is narrow and specific: identification evidence, the transactions themselves, the decisions you took about them. A minimisation and erasure obligation applies to everything you hold, including the parts nobody is compelled to keep — marketing preferences, device fingerprints, session history, support-chat transcripts, the profile photo, the recommendation features you derived. Once you draw the boundary at field level, most of the perceived conflict disappears, because the compelled set is usually a small fraction of what the row contains.

This is why the first artefact is not a design but a list. Someone in compliance has to state, in writing, exactly which fields are retained under which obligation and for how long. Engineers cannot infer that list and should not try; the reason the number is five years or seven, and the reason a particular field counts as identification evidence, comes from the rules your organisation is subject to and from your own legal or compliance function's reading of them. What engineering owns is the consequence: once the list exists, everything not on it is deletable on schedule, and that is an enforceable rule.

Retention is a property of a purpose, not of a table

Model retention against purposes rather than storage locations. A single customers row can carry data held under three different clocks — contract data that lives while the relationship runs, AML evidence that starts its clock when the relationship ends, and analytics attributes that should expire in months. A table-level TTL cannot express that, so it always resolves to the longest clock, which is how organisations end up retaining everything for the maximum period and calling it compliance.

The workable shape is a retention schedule that names purpose, the data it covers, the trigger that starts the clock, the duration, and the action at the end. The trigger matters more than engineers expect, because "five years" is meaningless without it: five years from creation, from last activity, or from account closure produce wildly different deletion dates for the same row.

Purpose	Data	Clock starts	Action at end
Serve the account	Contact details, credentials, preferences	Account closed	Delete
Identity verification evidence	Document images, verification result, checker identity	Relationship ended	Delete after the statutory period
Transaction records	Amounts, counterparties, timestamps, decisions	Transaction date	Delete after the statutory period
Personalisation	Behavioural features, derived scores	Last interaction	Delete on a short cycle
Do-not-contact suppression	Salted hash of the contact identifier only	Suppression request	Retain while the list exists

Put the retained set somewhere the product cannot reach

The dangerous outcome is not retaining the data. It is retaining it in the same store the application queries, where it stays available to every future feature. Purpose limitation is the obligation that gets broken silently, because nobody decides to reuse the data — a service simply joins to a table that happens to still be there.

So move the compelled set out. A separate schema or a separate service, written once by the onboarding or transaction path, readable only by named investigators through an interface that records who read what and why, with no network path from the product's runtime identity. Encrypt it under its own key so that access is a key-policy decision as well as a database grant. When the retention period expires, the deletion job for that store runs on its own schedule and does not depend on anything the product does.

This also makes the audit story tractable. An auditor asking whether you deleted the non-compelled data is asking about the operational store, and an auditor asking whether you preserved the compelled data is asking about the restricted store. Neither question requires you to reason about a table that answers to two masters.

Deleting someone while remembering not to contact them

The case that trips people up is the suppression list. You honour an erasure request, delete the account, and three weeks later the same email address receives a marketing send because the campaign source no longer knows to exclude it. Deleting the data made the outcome worse.

The resolution is that suppression needs the minimum token that supports the decision and nothing else: a salted hash of the identifier, no name, no history, no reason text, and no link back to the deleted account. The list can answer "is this address suppressed" and cannot answer anything else. It is worth stating explicitly in an interview that a hash of an email address is still personal data in most readings — it identifies an individual to anyone who holds the address — so this is minimisation rather than anonymisation, and it is the sort of point where you say plainly that your privacy function signs off the approach rather than asserting it yourself.

The same logic applies to erasure markers generally. Recording "subject 4471 was erased on this date" so that a replayed event or a restored backup does not resurrect them is a retention decision with a purpose, and it belongs on the schedule like any other.

Where candidates lose the question

The weak answer picks a winner. Either privacy is treated as an obstacle to be waived by pointing at the regulator, or minimisation is applied so bluntly that records needed for a regulated process vanish and an audit finding follows. Both signal that the candidate has not seen the two obligations coexist.

The other failure is quieter and more common in strong candidates: producing an elegant field-level design while inventing the retention periods. Naming a duration you cannot source is worse than saying the schedule is an input, because a wrong period is a defect that only surfaces years later when the data you needed is gone or the data you should have destroyed turns up in a discovery request.

The engineering deliverable here is a field-level retention schedule with explicit clock triggers, and an enforced boundary between the store the product reads and the store you are compelled to keep. The durations on that schedule are not yours to choose.